Networking question

[Chris Johns]

Leon Pollak wrote:
> Hello, all.
> 
> I have one TCP socket which is used simultaneously by 10 tasks (according to 
> my checks in the internet, this is allowed, yes?).
> 
> Tasks 1-9 are looping on writing something with about 20Hz frequency 
> (send(so,...) then 20ms sleep), task 10 (which opened the socket) does 
> read(so...), which has a packet once in half an hour.
> 
> 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.

> In 30% of good cases, all send(so...) finishes with -1 and read(so,...) as 
> well.
> 
> 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.

You could increase the buffer size in the socket. I think this is the 
SO_SNSBUF option of the setsockopt call. A FreeBSD man page will help here. 
You should be able to calculate the amount of space needed for each task to 
write its data. This will only work if your send rate is less than the network 
speed and the receive rate at the other end.

> 
> Can somebody of network gurus explain me my error?
> 

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.

I hope this helps.

Regards
Chris