Networking question

[Leon Pollak]

On Saturday, 3 בMay 2008, Chris Johns wrote:
> > The problem occurs in about 70% of the cases when on the other side (PC
> > with Windows XP) user cancels the application.
> When a remote socket is closed the local socket read will return with a
> length of 0. This means the socket has died. I suggest you check for this
> and flag to the sending tasks not to send anything more into the socket.
This is what I do already. Thanks.
But this does not help...


> > Very nice, except that there are other 70%, when the "read" operation
> > ends with -1, while almost all send's do not (some times one does).
> > When I dump out the tasks states in the bad case, I see that all these
> > are waiting for events (which is not my case, as I do only
> > rtems_task_wake...).
> This is the way the socket implementation works. The socket has blocked the
> sender. I suspect not enough space to write the data into so your tasks are
> blocked.
Hmmm..... Why?
I was sure that the problem is (as this is TCP not UDP) in that the remote 
socket does not send acknowledge and therefore sending blocks.

What you say is that send(so,...) will not block (if there is enough space) 
even without acknowledge?


> Do not close the socket with tasks in socket calls. That is do not close
> the socket from the read task when you read 0 bytes until all sending tasks
> have returned. This will result in a crash.
Hmmm!
This does not crash in my case but simply hangs on waiting for events.

I was sure that closing the socket while it is in the sending process will 
abort waiting for ack, while further sendings will be ignored.
But you say - this is incorrect assumption.


> I hope this helps.
Sure. Thanks again.

-- 
Leon