Hi Jacob, On 11/08/2010 07:15 PM, Jacob Joseph wrote:
[...] > Eloy, the tcp connection being closed is definitely the cause. There's > a FIN sent by the server after exactly 1 hour idle. Yup, this is exactly what I saw, packet by packet. The behavior is documented (--timeout_persistent_high in owserver's man page) and makes sense. I do wonder, however, if it is not a bug that an application keeps a connection alive after the server has closed the server to client side of the connection. The owfs application exhibits this behavior, and so does your application. The server has indicated, by sending the FIN, that it does not intend to send anymore data, so why would the application keep the client to server side of the connection open? Wouldn't proper application behavior be to close the connection upon receipt of the FIN and re-connect next time there is a need to read from the server? I haven't programmed at this level, though, so I don't know how the application (client) knows that the server has closed the server to client side of the connection, if that's possible to know. As a side note, I don't know if there are more packets in the capture and you just didn't include them below, so this may be old news, but in the case of the owfs application, after the connection is reset by the server, owfs reconnects again, automatically, causing a second read to succeed with no manual intervention. Anyway, glad you're making progress; let us know what you find. Cheers, Eloy Paris.- > I'll take a closer > look in time, but, for now, here are the packets: > > last packet before going idle: > > 18:02:16.751481 IP (tos 0x0, ttl 64, id 43050, offset 0, flags [DF], proto > TCP (6), length 52) > zaru.nuke.56502> zaru.nuke.4304: Flags [.], cksum 0x477a (incorrect -> > 0xd485), seq 26, ack 722, win 513, options [nop,nop,TS val 36893057 ecr > 36893057], length 0 > 0x0000: 4500 0034 a82a 4000 4006 4b46 c0a8 6301 e.....@.@.KF..c. > 0x0010: c0a8 6301 dcb6 10d0 7625 71aa 761a 260a ..c.....v%q.v.&. > 0x0020: 8010 0201 477a 0000 0101 080a 0232 f181 ....Gz.......2.. > 0x0030: 0232 f181 .2.. > > > After one hour idle: > > 19:02:16.929998 IP (tos 0x0, ttl 64, id 50192, offset 0, flags [DF], proto > TCP (6), length 52) > zaru.nuke.4304> zaru.nuke.56502: Flags [F.], cksum 0x477a (incorrect -> > 0x562e), seq 722, ack 26, win 512, options [nop,nop,TS val 37253075 ecr > 36893057], length 0 > 0x0000: 4500 0034 c410 4000 4006 2f60 c0a8 6301 e.....@.@./`..c. > 0x0010: c0a8 6301 10d0 dcb6 761a 260a 7625 71aa ..c.....v.&.v%q. > 0x0020: 8011 0200 477a 0000 0101 080a 0238 6fd3 ....Gz.......8o. > 0x0030: 0232 f181 .2.. > 19:02:16.969946 IP (tos 0x0, ttl 64, id 43051, offset 0, flags [DF], proto > TCP (6), length 52) > zaru.nuke.56502> zaru.nuke.4304: Flags [.], cksum 0x477a (incorrect -> > 0xd7d1), seq 26, ack 723, win 513, options [nop,nop,TS val 37253079 ecr > 37253075], length 0 > 0x0000: 4500 0034 a82b 4000 4006 4b45 c0a8 6301 e.....@.@.KE..c. > 0x0010: c0a8 6301 dcb6 10d0 7625 71aa 761a 260b ..c.....v%q.v.&. > 0x0020: 8010 0201 477a 0000 0101 080a 0238 6fd7 ....Gz.......8o. > 0x0030: 0238 6fd3 .8o. > > upon 'ls': > > 19:06:50.802956 IP (tos 0x0, ttl 64, id 43052, offset 0, flags [DF], proto > TCP (6), length 78) > zaru.nuke.56502> zaru.nuke.4304: Flags [P.], cksum 0x4794 (incorrect -> > 0x3cad), seq 26:52, ack 723, win 513, options [nop,nop,TS val 37280462 ecr > 37253075], length 26 > 0x0000: 4500 004e a82c 4000 4006 4b2a c0a8 6301 E..N.,@....@.k*..c. > 0x0010: c0a8 6301 dcb6 10d0 7625 71aa 761a 260b ..c.....v%q.v.&. > 0x0020: 8018 0201 4794 0000 0101 080a 0238 dace ....G........8.. > 0x0030: 0238 6fd3 0000 0000 0000 0002 0000 0004 .8o............. > 0x0040: 0000 0105 0000 0000 0000 0000 2f00 ............/. > 19:06:50.803033 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP > (6), length 40) > zaru.nuke.4304> zaru.nuke.56502: Flags [R], cksum 0xdee0 (correct), seq > 1981425163, win 0, length 0 > 0x0000: 4500 0028 0000 4000 4006 f37c c0a8 6301 E..(....@.@..|..c. > 0x0010: c0a8 6301 10d0 dcb6 761a 260b 0000 0000 ..c.....v.&..... > 0x0020: 5004 0000 dee0 0000 P....... > > ~Jacob > ------------------------------------------------------------------------------ The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book "Blueprint to a Billion" shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev _______________________________________________ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
