[PD] question about netclient and netserver

[Roman Haefeli]

On Wed, 2010-03-24 at 15:58 +0000, martin.peach at sympatico.ca wrote:
> reduzierer wrote:
> >>From what I know, there is an internal buffer of ~4kB for the sending
> > sockets in both netclient and netserver (I can't recall whether this
> > buffer is built into the externals or is part of the network subsystem
> > of the OS). If that limit is hit, the Pd process is blocked until that
> > buffer is emptied again (which leads obviously to audio drop-outs).
> >
> > IMHO, this is a design flaw, which all sending net-externals suffer
> > from. There is no way to check the state of this buffer, which would be
> > required in order to avoid a buffer overrun. It would be sufficient to
> > get notified only, when the buffer is completely emptied, so that you
> > could design your patch in a way that it would only send the next
> > message when the previous one is through.
> >
> 
> IMHO it's not a design flaw, but part of TCP's design philosophy that tries to send packets until they are received. In the original concept, bombs would be dropping all over the countryside, destroying cables and data centres willy-nilly, while messages could still get through to the missile silos and AA gunners.

The fact that those externals/objects block the Pd process has nothing
to do with TCP's design philosophy. I am no expert in this field, but I
know of other implementations in other programming languages, that
handle such situations more gracefully, for instance the python twistd
server, which the new netpd-server is built upon. 
Imagine an Apache server being completely blocked, because one of its
clients refuses to receive the webpage quickly enough. But this is the
current situation with the Pd net externals. Don't get me wrong, there
is no point in rebuilding Apache in Pd, nor am I demanding from anyone
that the situation needs to be changed. Those net externals generally
are very useful and cover a wide range of applications, but they fail
also in other situations and that has _nothing_ to do with TCP's design,
they fail because the implementation of those objects is not designed to
handle those situations.

> UDP was designed to send and forget.

Yeah, which makes the implementation of high-level
objects/functions/externals probably much easier (I imagine, but I don't
really know).

Roman



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