Re: tasksing and TCP sockets

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Tue, 31 Jan 2006 21:55:57 +0000, Simon Wright wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> On 30 Jan 2006 14:12:51 -0800, Rolf wrote:
> 
>>>  - I don't know much about sockets (or better I don't remember much).
>>> Does a waiting read (in the second task) block a write in the first
>>> task?
>>
>> Usually not. Note that you must wait not for a socket read, but for a
>> "variable-update" event from the middleware layer.
> 
> _Something_ has to wait for a socket read! If you're writing your own
> 'middleware' (lower layers, anyway) that will be you.

It depends. The point is, that it should not the application task.
Especially because socket I/O events are not directly mapped into
application events, due to buffering. So if the application needs fresh
data it can wait for a protected object, which state is changed by the
reader task (the reader waits, of course.) However more often, when dealing
with sensors and actors (which are continuous-state things), the
application does not wait at all, but just takes the last available value.
[ Quality of service checks, and generating consequent alarms is a
middleware's responsibility. ]

>>>  - what other hints can you give me?
>>
>> Never ever use UPD, avoid TCP_NO_DELAY with TCP/IP. The first is
>> unreliable for your purpose, the second quickly brings the network
>> down.
> 
> Probably best to avoid these (I guess that UPD was a typo for UDP) at
> the start, but sometimes they are the appropriate solution. Not often,
> maybe.

Yes.

Maybe off-topic, but. Multicasting finally came. Now there are viable
alternatives to UDP. For example, PGM is a reliable multicasting protocol.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de