[PD] tcpclient sending more than 1 send at once

[Roman Haefeli]

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)

> 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 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. 

roman
 


		
___________________________________________________________ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de