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

[Hans-Christoph Steiner]

On Dec 13, 2010, at 10:19 AM, Roman Haefeli wrote:

> 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

I've never heard of an app do so much network buffering.  At some  
point, that data needs to be processed, not just buffered.  If you end  
up having a giant buffer, chances are there is a problem that needs to  
be dealt with.  Might as well deal with it after a couple of megs are  
filled rather than just some

 From what I've seen, most network buffering is done with a ring  
buffer, so a fixed size.  That's my two bits...

.hc



----------------------------------------------------------------------------

Using ReBirth is like trying to play an 808 with a long stick.    - 
David Zicarelli