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 _______________________________________________ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev