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

[Roman Haefeli]

On Sun, 2009-03-01 at 12:56 -0500, Martin Peach wrote:
> 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]
> 

ah, now i see your example, i understand how the additional information
is supposed to be used. however, i never see a 'sent 0' message. even
after pluging the cable back again, so that the buffer is flushed, there
is no 'sent 0' message, but only lots of 'sent 1 7' messages. this
means, that this example patch didn't work for me. pd was blocked after
5700 or so 8-byte messages.

this is with a build from yesterday, so i will check out the todays
build as well. you'll hear again from me soon. ;-)

roman




	
		
___________________________________________________________ 
Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de