For a C# webservice that contacts a limited set of other servers, I wish to create 1 HTTP connection pool per server that I want to be able to contact.
The basic concept of course:
Each pool should open a few connections (3 connections?) to its remote webserver, and keep those connections alive.
A max-time-to-life should be used to recycle (disconnect/reconnect) the connections to the remote webserver, preventing the remote web server to disconnect before we do.
The connections should not be created simultaneously but with a little pause between the 3 connections so the recycling also does not happen simultaneously.
If the remote webserver still does disconnect unexpectedly, it should be noticed and we should reconnect.
If reconnecting is not possible for some reason, a retry should be done after a little pause.
This way, when I want to send a HttpWebRequest, I have ready-to-use connections, sparing the time of setting up the connection at the moment that I want to use it.
At the moment I don't know if this is even a default feature of HttpWebRequest. So sorry if I'm asking for the obvious. Googling for this only led me to similar questions for Java.
Question 1: is there such a thing present in .NET/c#?
Question 2: if not, is there a resource on this present on the internet, that you know of?
Question 3: if not, how to approach building one myself?
HttpWebRequest (which essentially means all Http APIs in .net) already makes use of connection pooling by default.
Take a look at ServicePoint and ServicePointManager classes if you need to manage any of the parameters of the connection pool.
Related
Making a client/server style app using WCF, but I can't find any documentation that explains if the NetTcpBinding provides a persistent connection?
I would like my client to connect and remain connected to the server for weeks at a time. (Yes I know I need to handle disconnects etc..)
Does the NetTcpBinding allow for a long connection such as this? If so is there anything I need to specify or is this default behaviour?
As long as you keep the service host and client proxy alive and opened, the underlying connection in WCF should remain opened as well. Even below that, it appears that the binding uses connections from the TCP connection pool, as found on the NetTcpBinding MSDN page:
The NetTcpBinding uses TCP connection pooling based on the service’s host DNS name and the port number the service is listening on.
I'm not an expert on how TCP connection pooling works, you may want to try a sister site such as ServerFault for more details on this.
If you want control over all this, then the only property I can see that can be tweaked for the out-of-the-box NetTcpBinding is MaxConnections. However, if you're really willing to dive deep you can also build your own Custom Binding with a TcpTransportBindingElement, that gives you even more fine-grained control on the TcpConnectionPoolSettings.
In any case, if I were to venture a guess I'd think building the service host and client proxy will take far more time (relatively) than any time spent getting a connection from the pool, so keeping those two opened may be enough for your requirements.
The reason I asked in a comment why you want the connection to remain open is because that can hardly be a requirement in itself. Speed and response times are a real requirement though, so the best advice is probably to make those requirements explicit (quantify / qualify your need for speed) and run some tests to determine what's best/needed for your situation.
I am developing a TCP server, which shall communicate with the client, if specified tasks are finished. So I open on the server a socket and the client connects on it.
That connection can be used for data tranfers back to the client, too. That is quite okay.
But what about connection aborts and anything like that?
My thought was to connect each time to the server, when the client have to communicate with it. But how can I send data back to the client?
Shall I open a socket on the client side, too?
EDIT:
I have considered WCF, too. I think it could be a very good way to implements server client hierarchy.
What do you think?
It depends on the rest of your requirements. If we're talking a message that is in no rush that might be sent once a day, the right solution might be for the client to connect to the server periodically and check if there are any messages. If we're talking something that's more common and more in a rush, the right solution might be for the client to keep a connection open to the server at all times. In some cases, the right solution might be for the server to make a 'backwards' connection to the client, if possible -- perhaps with an option to fall back to a persistent connection from the client to the server if the 'backwards' connection isn't possible.
See this article on Push technology, particularly the section on long polling.
From a runtime POV having the server connect to the client needs a network environment supporting this (firewall/IDS etc.).
IF you can't be sure that this is always the case then this option is ruled out IMO.
As for the client keeping the connection open:
I think this is a good option... you need to make sure that the client implementation detects any connection problems and automatically reconnects...
Whatever solution you implement you might need to implement a queue of events per client... depending on your requeirements these queues might even need to be persistent...
WCF can work in all the ways I described and offers several things (like serialization, optional session management, transport security etc.) which help build a robust and well-maintainable system... although a pure TCP/IP-based solution might be better performance-wise...
I have a problem, I've developed a Client and Server wrapper for my personal use, but unfortunately due to insufficient knowledge in network programming, I have TIME_WAIT problems during connect on the client. My client tries to make multiple connections to the same host within short period of time now, I have found out that the main reason for that is because I'm trying to reuse the socket and it goes to TIME_WAIT state because I'm closing the connection without graceful shutdown. I would like to know the correct pattern to close connection using .NET sockets in case I'm using 'Async' APIs intensively i.e. functions like ConnectAsync, AcceptAsync, SendAsync, ReceiveAsync, DisconnectAsync (DisconnectAsync - reuses socket)
I have found out that it is impossible to prevent TIME_WAIT. Either server or client will have the problem any way, depending only on who initiates a closure of the connection first. If it's the client who closes the connection, there will be no TIME_WAIT on server. If it's the server who closes first, than there will be no TIME_WAIT on client. So the only option that is left to do is using SO_REUSEADDR, but in this case it is still impossible to use the reused address for contacting previously disconnected host
You can use SO_REUSEADDR on the socket to get around this. See Socket.SetSocketOption for details, it's the ReuseAddress option you need to set.
By the way you don't really mean reuse the socket do you? once you get an error, you have to close it and open a new one.
I've got a project where I'm hitting a bunch of custom Windows Performance Counters on multiple servers and aggregating them into a database. If a server is down, I want to skip it, and just continue on with my day.
Currently I'm checking to see if a server is live by doing a DirectoryInfo on a share that I've got to look at later in the process anyways, then checking the .Exists property.This is my current code snippet for testing:
DirectoryInfo di = new DirectoryInfo(machine.Share_Path);
if (!di.Exists)
{
log.Warn("Could not access " + machine.Name + "! Maybe its down?");
continue; // Skips to the next server in my loop where this snippet exists.
}
This works, but its pretty slow. It takes about 68 seconds on average for the di.Exists bit to finish its work, and I ideally need to know within a second whether or not a server is accessible. Pinging also isn't an option since a server can be pingable but not "live" in our environment.
I'm still kind of fresh to the .NET world, so I'm open to any advice people can offer.
Thanks in advance.
-Weegee
Ping First, Ask Questions Later
Why not ping first, and then do the di.Exists if you get a response?
That would allow you to fail early in the case that is not reachable, and not waste the time for machines that are down hard.
I have, in fact, used this method successfully before.
MSDN Ping Documentation
Paralellize
Another option you have is to paralellize the checking, and action on the servers as they are known to be available.
You could use the Paralell.ForEach() method, and use a thread-safe queue along with a simple consumer thread to do the required action. Combined with the checking method above, this could alleviate almost all of your bottleneck on the up/down checking.
Knock on the Door
Yet another method would be to ckeck if the required remote service is running (either by hitting its port directly or by querying it with WMI).
Since WMI is almost always running when a machine is up, your connection should be very quick to either succeed or fail.
The only "quick" way I think to see if it's up without relying on ping would be to create a socket, and see if you can actually connect to the port of the service you're trying to reach.
This would be the equivalent of telnet servername 135 to see if it's up.
Specifically...
Create a .NET TCP socket client (System.Net.Sockets.TcpClient)
Call BeginConnect() as an asynchronous operation, to connect to the server in question on one of the RPC ports that your directory exists code would use anyway (TCP 135, 139, or 445).
If you don't hear back from it within X milliseconds, call Close() to cancel the connection.
Disclaimer: I have no idea what effect this would have on any threat/firewall protection that may see this type of Connect / Disconnect with no data sent activity as a threat.
Opening Socket to a specific port usually does the trick. If you really want it to be fast, be sure to set the NoDelay property on the new socket (Nagle algorithm) so there is no buffering.
Fast will largely depend on latency but this is probably the fastest way I know to connect to an endpoint. It's pretty simple to parallelize using the async methods. How fast you can check will largely depend on your network topology but in tests for 1000 servers (latency between 0-75ms) I've been able to get connectivity state in ~30 seconds. Not scientific data at all but should give you the idea.
Also, don't ever do this through UNC file shares because if the server no longer exists you will have a lot of dangling connections that take forever to timeout. So if you have a lot of servers with invalid DNS records and you try to poll them you will bring Windows down completely over time. Things like File.Exists and any file access will cause this.
The "Full-Blown" option would be to install a monitoring tool like SCOM (System Center Operations Manager), this has an SDK you can use to query SCOM for (performance) and maintenance information avout machines being monitored. Might be a bridge to far though....
Telnet is another option. Try telnetting to the target machine to see if it responds.
Create a small Windows Service that you install on your target machine, have the sys admin stop it when they perform maintenance on the target machine (just use batch file to net stop / net start the service)
I've got a c# WINDOWS Application that is multi-threaded. It is my understanding that in a web environment, connections are pooled automatically. It is also my understanding that in a Windows app, this is not the case. Therefore, for a Windows app, the same connection should be used and not closed after each call, but instead closed when the app shuts down.
I'm curious though - is my correct? If it is, can two threads use the same connection to get a dataset from the DB at the same time or is that functionality queued up?
Thanks
The Connection Pooling is one feature of ADO.NET. Therefore the connections are already pooled. Not only in the web environment.
http://www.ondotnet.com/pub/a/dotnet/2004/02/09/connpool.html
It is my understanding that in a web
environment, connections are pooled
automatically. It is also my
understanding that in a Windows app,
this is not the case.
No, this is wrong, as m3rLinEz pointed out. Connections are always pooled.
Therefore, for a Windows app, the same
connection should be used and not
closed after each call, but instead
closed when the app shuts down.
You could keep a connection open for the duration of the application in a monolithic WinForms app. But it's better to use the standard pattern of opening/closing connections whenever you need them. Connection pooling means you won't notice a performance difference. And your data access code will be compatible with server applications such as ASP.NET.
If it is, can two threads use the same
connection to get a dataset from the
DB at the same time or is that
functionality queued up?
No. The ADO.NET classes (connection, command etc) are not thread-safe and should not be shared between threads without synchronisation. But as noted above, you should prefer the standard pattern for data access.
ok - so this assumption of mine was brought on by observation: When I tried a win app setup in the typical pool fashion, I always experience a 3-5 second delay while a real connection is established to the remote server. Even when I did an open, then a close, the next query would always have this delay.
When the server connects, it obviously doesn't establish a connection for each connection in the pool. Also, is the pooling mechanism smart enough to grab a connection that it knows is already open or is it possible for it to simply grab any random connection?
What is the default max connections in the pool?