[PD] tcpclient sending more than 1 send at once

[Martin Peach]

Roman Haefeli wrote:
> On Mon, 2008-09-08 at 21:26 +0000, Martin Peach wrote:
>> Roman Haefeli wrote:
>>> all i need is a _robust_ OSC over TCP implementation. the bandwidth used
>>> is not high in average, but i cannot make any assumptions about peaks,
>>> it could well be that 2000 packets are sent at the same time.
>> If you send 2000 packets from one machine to another wouldn't that be 
>> construed as a denial of service attack?
> 
> no. would it, if you upload a 1 gig file to a file server? (which is
> basically the same from tcp's perspective)
> 

Oh. I thought you meant 2000 packets at the same time, which would imply 
2000 threads running at once.

>> Surely you can compress the information into fewer packets, say by using a 
>> single OSC message to send an array of values.
> 
> in some cases yes, but in this particular case it is not possible. if a
> new client connects netpd, it request a state dump from another client,
> this other client sends the dump immediately. i don't know how to
> compress state dumps from a an arbitrary number of instruments with an
> arbitrary number of parameters with arbitrary message format and
> arbitrary number of elements. but this is just some arbitrary example. i
> generally don't think, that i am trying to use OSC in a wierd manner. 
> 
>> Unless you mean 2000 machines are sending single packets to one machine, in 
>> which case the packets will all be separate, there's no problem apart from 
>> overloading the cpu for a few seconds.
> 
> in netpd everything is possible. there is an arbitrary number of
> [tcpclient]s connected to one [tcpserver], while the patch with
> [tcpserver] is acting as an OSC proxy, that forwards incoming OSC
> packets to one or more clients. see more details on
> http://www.netpd.org/server

It sounds like it could crash the same way stock exchange software 
sometimes crashes when there is too much trading volume. The model 
relies on an inexhaustible pool of memory and cpu time.

> 
> it used to work well with FUDI (besides the monthly netpd-server
> crashes), since [netserver] and co don't seem to rely on tcp packeting,
> but use a delimiter ';\n' to separate packets. however, the same thing
> doesn't work, when i switch to OSC. i can just repeat myself: all
> trouble comes from [unpackOSC]'s unability to create packets on its own.
> any pd project based on OSC/TCP will potentially suffer from this
> problem, it is not only because of some (assumed) strange way of using
> OSC. if [unpackOSC] is meant to be used only under _certain_
> circumstances, i think, it should be documented accordingly. 
> 

The idea is to expand it to fit circumstances as they arise. I hadn't 
really tried OSC over TCP, so I wasn't aware of this problem. I agree it 
needs fixing, I'm just not sure of the best way at the moment. It could 
be simpler to prefix the OSC packet with its length. Then a list 
abstraction could reassemble incoming lists and send them to [unpackOSC] 
one OSC packet per list.

Martin