[PD] pd and tcp: what to do against crashes?

[Martin Peach]

Roman Haefeli wrote:
> On Tue, 2009-02-24 at 21:15 +0000, Martin Peach wrote:
>> Roman Haefeli wrote:
>>> --- Martin Peach <martin.peach at sympatico.ca> schrieb am Di, 24.2.2009:
>>>> Roman Haefeli wrote:
>>>>>>> On Mon, 2009-02-23 at 21:03 +0000, Martin
>>>> Peach wrote:
>>>> Yes, I agree. I think a status outlet on the [tcpserver]
>>>> could be extended later to have more messages. Some of the
>>>> stuff that gets printed to the Pd window could go there and
>>>> then it could be handled by the patch instead of the
>>>> 'operator'. I don't want to keep adding more
>>>> outlets, so it would output lists with a selector, like
>>>> [comport].
>>> i totally agree, that instead of adding more outlets it would be better to 
>>> provide additional information on the same outlet with appropriate 
>>> selector.
>>>
>> OK it's done for now, in svn. Each time something is sent, you get a "sent" 
>> message from the status outlet that gives the number of bytes that were 
>> actually sent and the client number. Also a [client( message with no data 
>> lists the connections using a "client" selector.
>> The send function doesn't wait any more. If the number of bytes sent is 
>> zero, you have to try again.
>> It all needs to be tested...
> 
> thank you for implementing those changes. 
> 
> i finally had a chance (and time) to have a closer look and it turned
> out, that the additional information is actually no gain and this still
> doesn't allow to programm a non-blocking server.
> it seems, that the 'sent' message is output, when something was _added_
> to the 'send' buffer. actually, we would need this message to appear
> when something was _removed_ from the buffer, which is when a message
> actually was sent. 


Yes, because the actual buffer is hidden from the user. You should get a 
'sent 0' message when it would block though, I don't know why you don't.


> 
> with the current implementation,  the buffer still overruns without
> having the chance to know this beforehand. whenever i send a message to
> client, i get _immediately_  a 'sent 1 7' message, which i use to
> trigger the next message, etc. so buffer keeps filling and filling. when
> the buffer is full, [tcpserver] blocks pd. so, currently the situation
> is not different from the one before i have started this thread.

It's not supposed to do that. It should return 'sent 0' when it can't 
take any more, never block. Are you sending to the same client or many 
different ones? Can you post a test patch that will reproduce the bug?
Something like this should stop when the buffer is full:

[bang][r stop]
|     |
[until]
|
[send 1 7 7 7 7 7 7 7(
|
[tcpserver]
| | | | |
         [route sent]
          |
         [select 0]
          |
         [s stop]

> 
> i don't know, how much control you have at c level over what is
> happening at tcp level. in order to solve the current issues at
> pd-level, information about either the current buffer size or amount of
> sent bytes  (number of bytes removed from the buffer) would be required.
> i don't know how and if this is possible at all.

I don't think it's possible (but then I'm often wrong ;(). There might 
be an ioctl that will return the buffer size so you could know how much 
is safe to send at once.

> 
> i would be interested to read about the c functions providing tcp
> capabilities. may i ask where you got your knowledge about those?
> 

 From all over, but usually from the man pages for tcp, send, ioctl, and 
the like. For Windows, MSDN has a lot of info about winsock, which is 
very similar to unix sockets.

Martin