Summary

TCP sockets get closed prematurely

Metadata

Attachments

Description

Running the attached programs leads to "Connection reset by peer" errors.

Changes and comments

[2011-06-19 13:05:03 UTC] syn attached listen.scm (description=#f)

[2011-06-19 13:05:11 UTC] syn attached client.scm (description=#f)

[2011-06-25 14:33:00 UTC] felix set cc to sjamaan

[2011-06-25 14:33:00 UTC] felix removed owner

[2011-06-25 14:33:00 UTC] felix changed component from unknown to core libraries

[2011-06-25 14:33:00 UTC] felix wrote:

While digging through my copy of Stevens "UNIX Network Programming", I came upon a section that deals with an example TCP client that, waiting for input from a server, gets into a state where it assumes the connection is reset. Not exactly the same, but this passage looked interesting:

"... That is why the client's call to `readline` returns 0 because the FIN that was received earlier is ready to be read. But if we run the client and server on the same host, or if we were to put a slight pause in the client before its call to `readline` , then the received RST takes precedence over the FIN that was received earlier. This would cause `readline` to return an error and `errno` would contain `ECONNRESET`."

I tried to find more information in the RFC, but that's much too dense for me. The gist of this is: is it possible that there isn't really an error situation, but an RST segment is sent by the server (out of whatever reason - perhaps just because the connection is dropped after closing, or so) and overtakes the FIN which would indicate a closing connection to the client? Perhaps there is a time-window between the call to `select` and reading from the socket that is too long?

Has this test been run on two different machines in the same LAN? (I just tested it on a single host (4.6.7, Linux) and everything runs fine).

[2011-07-04 12:47:12 UTC] syn wrote:

Sorry for replying late, this somehow slipped my attention.

I have only tested it on my machine through the loopback interface so far. Maybe a tcpdump or something like this would reveal if that's what's happening. I'm a bit clueless about all that TCP stuff but will try to figure it out!

[2011-07-04 23:32:09 UTC] sjamaan wrote:

I tried to run the test code again, but keep getting segfaults in the client with HEAD chicken :(

It crashes pretty consistently in f_943 in scheduler.c (which is ##sys#interrupt-hook), even if the server testing code is not running.

Enabling different debug options causes it to fail in slightly different places, but it's just before it calls ##sys#schedule

It looks like this was caused by changeset 7cd875bb13f2efd2af83a9f8d82217101e4e85a3 because reverting it causes the code to work again.

[2011-07-04 23:36:32 UTC] sjamaan wrote:

(this is on netbsd/amd64)

[2011-07-04 23:39:22 UTC] sjamaan wrote:

After reverting the patch I get several of these in the client:

 Warning (#<thread: thread843>): (tcp-connect) cannot connect to socket - Bad file descriptor
 "localhost"
 8080

and then finally the familiar

 Warning (#<thread: thread271>): (tcp-connect) cannot create socket - Connection reset by peer

[2011-07-05 21:57:01 UTC] sjamaan wrote:

The connect error happens because of the backlog being 4 by default. If I change listen.scm to have a larger backlog by doing (tcp-listen 8080 100) the client continues doing its work and stops normally after a very short time.

[2011-07-05 22:01:57 UTC] sjamaan wrote:

Probably the default should be raised as this gives networked Chicken apps a bad name; if it's raised the client exits almost immediately instead of hanging for a while. Now Spiffy's performance is closer to node.js

[2011-07-05 22:08:20 UTC] sjamaan wrote:

(actually, the backlog is 10, not 4; the docs are wrong)

[2011-07-06 08:03:46 UTC] felix wrote:

Replying to sjamaan: > It looks like this was caused by changeset 7cd875bb13f2efd2af83a9f8d82217101e4e85a3 because reverting it causes the code to work again.

Very strange. I have removed all uses of the error fdset from the scheduler (it wouldn't have been useful anyway). Why this crashes I can't explain.

[2011-07-06 08:04:57 UTC] felix changed status from new to closed

[2011-07-06 08:04:57 UTC] felix set resolution to fixed

[2011-07-06 08:04:57 UTC] felix wrote:

I raised (and documented) the default backlog to 100.

[2011-08-15 19:43:14 UTC] mario wrote:

What's the expected behavior of this test? I get

 Warning (#<thread: thread871>): read operation timed out
 60000
 178
 
 Error: uncaught exception: #<condition: (exn i/o net timeout)>

-like errors when I run client.scm against listen.scm.

[2012-09-24 21:47:48 UTC] felix changed milestone from 4.8.0 to 4.9.0

[2012-09-24 21:47:48 UTC] felix wrote:

Milestone 4.8.0 deleted