From: lcargill99@comcast.com
Rick Jones wrote:
> Les Cargill wrote:
>> I am writing a TCP server. It is running on an embedded linux
>> platform, not a workstation. Yes, I have full source to the kernel
>> and all drivers.
>
>> If the following sequence occurs, send()crashes without
>> returning:
>
>> Client Server
>> send()
>> select()
>> recv()
>> close()
>> send() *crashes*
>
>> I somehow don't think it is supposed to do that.
>
> If the timesequence is as you give it, modulo the distance between the
> two systems, that send() call would certainly elicit a TCP RST (ReSet)
> segment from Client.
>
I did not mention that the client is Windows XP.
>> How can I tell the socket is closed before calling send()?
>
> I presume you mean the *remote* socket has been closed?
Yessir - the client has called close() on that socket.
> That is
> indicated locally by a read return of zero on the socket.
Yeah, the usual story.
> When Client
> called close(), that caused TCP to send a FINished segment to Server.
> That FIN segment is Client TCP's way of saying to Server's TCP "I am
> sending you no more data." Server's TCP indicates that to the
> application by causing the recv() issued after any queued data is
> received to return a value of 0. What it means beyond that (eg that
> Client expects to receive no more data) is up to the application
> "protocol." A FIN could have been triggered by Client calling
> shutdown(SHUT_WR) against the socket at its end. Thus why the
> interpretation of the read return of zero being more than "There is no
> more data coming" is a matter of application protocol design.
>
>> please spare the assembled any "but it's not supposed to do that".
>> It does; it's likely a bug and not one I will spend any time chasing
>> if I can find a workaround.
>
> What do you mean by send() "crashes?"
The program exits without complaint.
> Do you mean your application
> crashes when it makes the send() call? Do you mean the system
> crashes?
>
The application exits without ceremony.
> Even if your Server checks for and correctly interprets the read
> return of zero before it goes to send(),
it does.
> there is still going to be a
> timing window - if Server does not send what I assume is a response to
> what I assume is a request of Client
correct...
> by the time Client gives-up and
> closes the connection, there will still be the chance that Server
> calls send() before the FIN segment from Client's close() arrives.
>
> Thus, if doing so does indeed cause some sort of "crash" in Server you
> will likely still have to address the crash.
>
> One way to further close the window would be, if you control Client,
> to have client call shutdown(SHUT_WR) and be willing to keep the
> socket around a while, draining it, until it too receives a read
> return of zero, indicating that Server has seen a read return of zero
> on its end and "acknowledged" it by closing at its end.
>
Right or wrong, I am not in a "read()" phase at this point in the
program. I *have* read; select() and recv() were called and
the client hung up before I could respond...
> More details are in the works of Stevens, Fenner and Rudoff and/or
> Stallings. Perhaps others. Useful references to have on hand when
> writing networked applications.
>
Good to know. In close to 30 years of writing stuff against sockets,
I've never seen anything quite like this before.
> rick jones
>
--
Les Cargill
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
