TCP socket close problem

Hello,

Since my previous tcp issue was resolved by posting here, I'll try
again, this time with another TCP problem. If someone knows of a good
network programming group to post to instead, please tell me so!

I've written a server app that listens to port 5000 on a FreeBSD
machine. Connecting works fine, and actually everything usually works
fine, except when some clients disconnect. The client's socket is
closed, and does not even show up in netstat (the clients are Windows
XP machines). On the server, however, the socket stays open, in
"ESTABLISHED" state. (Not even CLOSE_WAIT.)

It would seem I'm doing something wrong, which prevents the server to
detect the closed socket, but I've added lots of trace output on the
server, and it does seem to set the client's socket descriptor in the
call to select(), but select() never returns saying that the
descriptor is readable.

The problem only happens when I client closes a "busy" socket, with
unacked data on the way to the client. And, as expected, the client
sends an RST after the FIN.

It all looks like I'm not properly detecting that recv() returns with
0 bytes (I think the server sends it FIN after close() is called on
the socket?), but I've scratched my head now for a long time...

Can somesone with more TCP experience help me think of possibilities
for this happening?

15:34:13.244087 IP 81-226-237-254-no61.tbcn.telia.com.2610 > multivac.fatburen.org.5000: . ack 699313 win 11680
15:34:13.256048 IP 81-226-237-254-no61.tbcn.telia.com.2610 > multivac.fatburen.org.5000: . ack 702233 win 8760
15:34:13.517164 IP 81-226-237-254-no61.tbcn.telia.com.2610 > multivac.fatburen.org.5000: F 118:118(0) ack 702233 win 8760
15:34:13.518210 IP 81-226-237-254-no61.tbcn.telia.com.2610 > multivac.fatburen.org.5000: R 119:119(0) ack 702233 win 0
15:34:15.199721 IP multivac.fatburen.org.5000 > 81-226-237-254-no61.tbcn.telia.com.2610: . 702233:703693(1460) ack 118 win 65535
15:34:21.275374 IP multivac.fatburen.org.5000 > 81-226-237-254-no61.tbcn.telia.com.2610: . 702233:703693(1460) ack 118 win 65535
15:34:29.953937 IP multivac.fatburen.org.5000 > 81-226-237-254-no61.tbcn.telia.com.2610: . 702233:703693(1460) ack 118 win 65535
15:34:47.115708 IP multivac.fatburen.org.5000 > 81-226-237-254-no61.tbcn.telia.com.2610: . 702233:703693(1460) ack 118 win 65535
15:35:10.040407 IP multivac.fatburen.org.5000 > 81-226-237-254-no61.tbcn.telia.com.2610: . 702233:703693(1460) ack 118 win 65535

BTW, I've tried reproducing the results on a Linux 2.6 server, but
somehow the code always works there.

Staffan
.

Relevant Pages

  • Re: Socket switch delay
    ... both at the client and at the server (and why ... would you set the send buffer size to zero on a non-overlapped ... One glaring error is your client does ... So when you use a single socket, ...
    (microsoft.public.win32.programmer.networks)
  • Re: Netzwerkproblem GBit -> 100MBit
    ... GBit-Kette - flow control zwingend notwendig sei. ... zwischen Client und Server. ... Das kann TCP an der Stelle nicht mehr leisten. ...
    (de.comp.sys.novell)
  • suspect bug in vge(4)
    ... The high-level view of the problem is that the client seems to stall ... HTTPS server. ... not only printed for TLS/SSL issues but simply also for broken TCP ... To me it sounds like a broken implementation of hardware generated ...
    (freebsd-current)
  • Re: Log Out Issues
    ... UDP is the way to go for internet games. ... Apparently the extra overhead in TCP can cause a lot more lag in your game, ... >> Lets say the client sends a log out request to the server reliably. ...
    (microsoft.public.win32.programmer.networks)
  • Re: Log Out Issues
    ... your perormance may be worse than TCP. ... would be if your protocol anticipates packet loss and does not ... >>> Lets say the client sends a log out request to the server reliably. ...
    (microsoft.public.win32.programmer.networks)