Megabitz offers service through a cluster of high performance Usenet news service. To offer the best variety of services at the lowest cost, our servers place hard limits on the number of connections each account can make to the service. From time to time, we receive complaints from users about "per-user limit exceeded," and in almost all cases, this is due to client configuration settings, sometimes brought on by other events.
Historically, NNTP is a protocol that did not provide a way for clients to terminate a connection while data is being transferred. When web browsers began to offer newsreading capability, they wanted the "Stop" button to work in the same way that it worked on the Web, and they made it happen in the same way it happens on the Web - by having the client hang up on the server. This is an exceptional situation, and what is supposed to happen isn't defined. Modern servers will handle it, of course, but it still shouldn't be done casually.
Some client authors, however, have decided that it is just fine to hang up on a server, and have actually built functions into their clients to do just that. This can cause problems by exercising something which should only happen under exceptional conditions on a much more frequent basis.
Clients, upon deciding to terminate a connection, simply perform a socket close which tells the operating system to close the TCP connection to the server. Most clients will then immediately reopen a new connection, since, after all, the old one is closed, right?
Wrong. Your PC must first signal to the server that the socket has been closed, and this requires an exchange of network traffic. If there is packet loss, or either end is busy, it can take a significant amount of time for the TCP layer to finish closing the connection, and the server has no way of knowing that the client has attempted to forcibly close the connection until this is complete.
Worse, even upon receiving that notification, the server must complete what it was doing for you, get back to the command state, notice that the connection is gone, terminate your connection, and then update the authentication server with your session close record. Only after all this happens will your per-user connection count decrease.
In the meantime, it is perfectly possible that your client has reconnected and tried to authenticate, and received an authentication failure.
When your client disconnects correctly, all of that is guaranteed to have happened by the time your client receives the acknowledgement to the QUIT command.
These problems can be made worse by a variety of factors. Anything that interferes with the communications between your client and the server can be a problem.
Firewalls
Many hardware firewalls attempt to implement "stateful" filtering of packets. A lot of software firewalls will do other filtering tricks as well. We've observed that a number of these products do not correctly deal with closing connections. This isn't a problem on the Web, since connections will ultimately time out at the TCP level, but can be a real problem for users unfortunate enough to be behind them while using a service like NNTP.
NAT
Similar to the hardware firewall situation, we've seen a lot of NAT devices that will release state information about a connection as soon as possible, not allowing for the case where the server doesn't get part of TCP's 3-way handshake to shut down a connection, and the firewall functionality prevents the device from emitting a reset packet. Due to the design of these devices, some content filtering devices are particularly prone to this.
Packet Loss
Packet loss on the general Internet can delay the TCP handshake that would notify our server of the closed state of the connection.
Because the server plays a critical role in decreasing the connection count for a user, if the news server is busy or the authentication server is loaded down, it can take a little extra time for the system to clear a connection. Since this is handled in-session for clients that properly close a connection, it isn't a problem for most clients. It is only a problem for clients that drop connections.
If you have any questions about this subject, contact us! We're here to help.