[PD] network problem with pd / [list-fifo]

[Mathieu Bouchard]

On Sun, 17 Dec 2006, Roman Haefeli wrote:

> netpd's major problem is the occurence of many dropouts in certain 
> situations. one reason is the way how all (at least all i know) network 
> related objects in pd handle buffer overruns. when the buffer of a 
> network object is full, the whole pd processing is stopped until the 
> buffer gets emptied again.

Pd doesn't handle all of its sockets like that. There's one special socket 
that handles it differently, and it's the socket that talks to the GUI 
process. In Pd 0.38, Miller added a bunch of special code in s_inter.c 
that allows it to do nonblocking writes and causes it to replace the 
output buffer by a bigger one.

The problems that I see with that are:

1. there's no way to limit the size of the output buffer. If the other 
side of the connection doesn't respond, the sending buffer just 
inflates quickly. I've seen it happen that a bug in the sender causes 
it to try to send so fast that it ate memory like an infinite recursion 
or a forkbomb.

2. That operation is not realtime-safe (but still it's much closer to 
being so than just blocking...)

3. It's only usable by the GUI socket and never by [netsend].

4. While that buffer together with t_guiqueue allow GUI updates to be 
delayed for as long as necessary, it doesn't solve the problem that it can 
send information that is already outdated and redundant. This can be 
important in preventing problem #1 for a very heavy GUI. DesireData has 
had this problem essentially dealt with since a long time, but it lacks 
some fine tuning to get more robust.

  _ _ __ ___ _____ ________ _____________ _____________________ ...
| Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju
| Freelance Digital Arts Engineer, Montréal QC Canada