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 _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
