Its also mostly irrelevant what the definition of "useless" is, or that is, it is unless you have decided that killing useless connections are OK, then you need to decide which ones in particular to go after ftp connections not transferring data that have been idle 15 minutes might be useless to one person, while to another they're harmless, but mailer processes that haven't received an SMTP command for 5 minutes are a disaster. If you put a timer on it, you lose, because it's perfectly legitimate for the other side to do some arbitrary computation and send more data, if you did a half- close!
But if you don't put a timer and the other side crashes, you hang literally, in the protocol sense forever. You have no unacked data and no timer running to make you send anything again. Most user interfaces won't allow you to do anything at the application level for this, because you don't have a writable file descriptor at that point. If I'm not using a connection at the time some intermediate gateway crashes, why should I lose all my state eg, login session , when, without keep-alives, I can resume where I left off as long as both ends remain up and the intermediate gateway that crashed has recovered?
That's one of the great advantages of packet-switching. Maybe implementations should allow system administrators to force keep-alives on particular connections if it appears they're hung.
I hate any fixed-timer solution, myself. You can't -- not without risking the clearing of a connection that! Both are stable states, and they should! The correct term for it ought to be "killalive", since that is what it does Phil --Johnny "When in doubt -- hesitate!
There's a third choice: ignore the problem. Are modern timesharing hosts so memory starved that they cannot tolerate even a few orphaned user tasks?
I have a dialup SLIP link from my house. I frequently stay logged in while puttering elsewhere around the house, so the link often stays up for hours at a time it's a local phone call. That would keep the line clear for faxes or other possible uses.
But keepalives would break this scheme. Chances are they would just keep my SLIP link dialed up unnecessarily. But if the gateway did in fact drop the link, keepalives from hosts on the other end would gratuitously abort my TCP connections because I don't want the Netblazer at work to call me. I prefer to place all of the calls from my end, so I can be assured of having control over the line. Also, incoming data calls would confuse my FAX machine.
As long as I don't have to contend with keepalives, this scheme will work great. I stop typing long enough from home, and the gateway drops the line. I start typing again, and the gateway redials the line; my own TCP is patient enough to wait for this to happen.
The upper part shows the states on the end-point initiating the termination. The lower part the states on the other end-point. So the initiating end-point i. Connect and share knowledge within a single location that is structured and easy to search. I am writing a socket based C application which seems to behave in a very unstable way.
The code is standard socket handling on TCP port , and I know it has worked before. Instead of mentioning the source code, I believe the most interesting are the results of the netstat -aon command:. When it does not work anymore, the results of the netstat -aon grep command are:.
Does anybody know the meaning of the mentioned "netstat" results, what this might mean for the socket handling and what can I do in order to return to the situation giving the first results? However, in the second case the server is ready to accept a connection, which to me sounds like you haven't established your TCP connection yet. Without really knowing what your C program is trying to do, it's hard to diagnose your issues here, but I would take a look at the documentation for netstat and go from there.
This is a normal behavior for a listening server socket which is not the same as the connection server socket. The server is probably waiting because there is data to read that was not yet read.
It can't close the socket without data loss, which is unacceptable for TCP. The connection should close normally after all the data left on the server side is read. Paul Pedant Posted March 2, 0 Comments. Windows WinSock apps are notorious for doing this to your server. Register or Login. Welcome back! Reset Your Password We'll send an email with a link to reset your password.
Stay ahead! Get the latest news, expert insights and market research, tailored to your interests. Sign in with email Enter the email address associated with your account. You auth link is expired or incorrect, please try again.
0コメント