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
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ 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
