On Tue, 2008-09-09 at 00:03 +0200, 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) > > > 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.
sorry, i guess i was sounding harsh. i understand, that you don't want to change [unpackOSC], if it means completely rewriting it. it's just sad, that netpd cannot make use of it as it is now. it would have been a big step forward. roman ___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list