[PD-dev] about [tcpserver] (mrpeach and iemnet)

[Roman Haefeli]

On Fri, 2010-12-10 at 10:54 -0500, Hans-Christoph Steiner wrote:
> On Dec 10, 2010, at 5:12 AM, IOhannes m zmölnig wrote:
> > On 12/09/2010 10:28 PM, Roman Haefeli wrote:
> >>
> >> @ IOhannes
> >> Though I like this 'stable'/reliable behaviour of iemnet's  
> >> [tcpserver],
> >> I wonder what happens, if it keeps sending data to the unreachable
> >> client. Will it just go on and buffer everything until the whole  
> >> RAM of
> >> the computer is consumed? If so, wouldn't it be more wise to just
> >> disconnect that client at some point in order to avoid the box  
> >> running
> >> out of memory?
> >
> > you can query the fillstate of the buffer from within the patch and  
> > act
> > upon that: if you prefer to disconnect after 300MB (because of the  
> > 2.5GB
> > memory you have, 2GB are only swap), or if you rather go and crash or
> > whatever...it's up to you.

Great! That's even better than to disconnect clients at some arbitrary
buffer size.

> A 300 MB network buffer!  That sounds scary.

It's not really a network buffer. If I understand correctly, it's the
RAM used by the Pd process that grows, when this buffer is filled. I
guess, there is nothing to be really scared about.

Anyway, there is no 'real' alternative to buffering data. When a certain
client is not totally responsive,  you either have to make the server
blocking ([netsend]/[maxlib/netserver]), or you decide to discard data
that cannot be delivered ([mrpeach/tcpserver]), or you buffer the data
([iemnet/tcpserver]). The last option is definitely the best, in my
opinion. 

Doing "networking with Pd" is special in that you use a real-time
oriented framework (Pd) together with a 'time-agnostic' one. TCP only
cares about _what_ is delivered, but not _when_. Accordingly, special
measures are necessary to join both worlds in a reliable way.

Roman