I could test for errno = EAGAIN or EWOULDBLOCK in that case, or is
this all unnecessary?
On Tue, Nov 16, 2010 at 12:08 PM, Jacob Joseph <ja...@jjoseph.org> wrote:
> Paul,
> I don't think that works. recv() returns -1 when there's no data to
> read.
>
> ~Jacob
>
> On Tue, 16 Nov 2010 11:54:45 -0500
> Paul Alfille <paul.alfi...@gmail.com> wrote:
>
>> Wou7ld modifying your patch to:
>> if (recv(scs->file_descriptor, test_read, 1, MSG_DONTWAIT |
>> MSG_PEEK) <= 0) { be appropriate to catch recv errors as a "close
>> connection" condition?
>>
>> Paul Alfille
>>
>> On Mon, Nov 15, 2010 at 4:58 PM, Jacob Joseph <ja...@jjoseph.org>
>> wrote:
>> > Oops. I introduced a typo while making a clean patch. The attached
>> > is correct.
>> >
>> > ~Jacob
>> >
>> > On Mon, 15 Nov 2010 16:50:51 -0500
>> > Jacob Joseph <ja...@jjoseph.org> wrote:
>> >
>> >> Hi.
>> >>
>> >> I believe it is sufficient to check the connection state
>> >> immediately before the client sends a command to the server. If a
>> >> read/recv returns 0 bytes, we know that the connection was closed.
>> >>
>> >> I was initially concerned that an ill-timed close could cause the
>> >> FIN to be read during the read, and missed. That is, for a
>> >> scenerio like
>> >>
>> >> (0) client writes, (1) server writes, (2) client reads, (0)...,
>> >>
>> >> the server could close the connection before 0, 1, or 2, as well as
>> >> during 1. Fortunately, recv (and read) appear to return zero for
>> >> every call after the TCP connection is closed at the server. A
>> >> connection closed during (1) will appear as a truncated payload,
>> >> and handled as is in tcp_read.
>> >>
>> >> A patch that appears to work for me is attached.
>> >>
>> >> ~Jacob
>> >>
>> >>
>> >> On Wed, 10 Nov 2010 21:54:55 -0500
>> >> Paul Davis <zi...@pumpkinbrook.com> wrote:
>> >>
>> >> > That's correct. The read returning 0 indicates the connection was
>> >> > closed, and the proper thing to do is close your own socket, thus
>> >> > completing the sequence. The proper thing to do next would be to
>> >> > set the state machine to the same state as before the connection
>> >> > was first made. Presumably then the DIR would cause the
>> >> > connection to be re-established and the rest of the directory
>> >> > read process would complete. I have not looked at the code (so I
>> >> > may be full of hot air) but hopefully you get the idea.
>> >> >
>> >> > There are multiple ways to detect the closed connection, which
>> >> > one best fits depends on the individual case. One simple
>> >> > solution is to have the server send a special message when it
>> >> > closes the connection. This can easily be caught by the client
>> >> > and the client can then close its end. Of course, this doesn't
>> >> > handle the cases where the server may be killed and the
>> >> > connection abandoned. I think you can also check for SIGPIPE if
>> >> > you try to write to the socket after the server has closed it
>> >> > (sorry, my sockets programming is a little rusty).
>> >> >
>> >> > Ziggy
>> >> >
>> >> > On 11/10/2010 5:08 PM, Jacob Joseph wrote:
>> >> > > Hi.
>> >> > >
>> >> > > I was taking a closer look at the code, and have a few
>> >> > > questions about how things work.
>> >> > >
>> >> > > In ow_tcp_read.c:tcp_read(), when the FIN packet comes in,
>> >> > > read() returns 0 bytes read, indicating an EOF. It then
>> >> > > returns 0. Is there any reason this should not be considered
>> >> > > an error?
>> >> > >
>> >> > > A bit further downstream,
>> >> > > ow_server_message.c:From_ServerAlloc() doesn't check the
>> >> > > return from tcp_ready() anyway, but does check that the
>> >> > > payload is of the right size. If it isn't, it returns
>> >> > > NO_PATH. This does lead the client to close the connection in
>> >> > > Release_Persistent(), but this doesn't prevent the empty
>> >> > > directory listing from coming back.
>> >> > >
>> >> > > This leaves me unclear of where to catch the closed connection.
>> >> > > Whenever read()==0, the other side has necessarily closed its
>> >> > > connection and the owfs client should do the same, then retry
>> >> > > the DIR.
>> >> > >
>> >> > > The closed connection looks identical to as when owfs is
>> >> > > started but there is no owserver running. It seems like a
>> >> > > directory listing should fail outright.
>> >> > >
>> >> > > I hadn't used the debugging output before. I'm very pleased
>> >> > > how comprehensive it is. Thanks!
>> >> > >
>> >> > > ~Jacob
>> >> > >
>> >> > >
>> >> > > On Mon, 08 Nov 2010 21:02:02 -0500
>> >> > > Eloy Paris<pe...@chapus.net> wrote:
>> >> > >
>> >> > >> 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
>
> ------------------------------------------------------------------------------
> Beautiful is writing same markup. Internet Explorer 9 supports
> standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
> Spend less time writing and rewriting code and more time creating great
> experiences on the web. Be a part of the beta today
> http://p.sf.net/sfu/msIE9-sfdev2dev
> _______________________________________________
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>
>
------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
