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

[Roman Haefeli]

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. 

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.

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 would be interested to read about the c functions providing tcp
capabilities. may i ask where you got your knowledge about those?

roman 


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