On Mon, 2008-09-08 at 20:41 +0000, Martin Peach wrote:
Roman Haefeli wrote:
i did a similar test with OSC bundles. it turned out, that you cannot rely on the packet becoming one single list on the receiver side. if it was splitted into two or more tcp packets during tcp transport, the OSC bundle becomes broken.
now i am rather more convinced, that any solution based on tcp packets instead of a tcp stream is not going to work.
I still don't know what you are trying to do so I can't say. If you are sending huge amounts of data constantly you really shouldn't be using OSC at all.
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. the idea is to port netpd to OSC. i don't think, that it is generally a bad idea. however, it will only work, if it can use the benefits of tcp, which is: make sure, that all data arrives intact and in the right order. netpd would break (not in all circumstances, but in many) if some packets would be dropped. currently i don't see, how i can make a robust OSC/TCP connection with pd.
You could make your own protocol that sends the length of the packet as the first three or four or even more bytes and then use the list objects to chop the stream into pieces. But Pd is really inefficient for this because it's going to convert every single one of your billion bytes into a symbol and put it in memory somewhere.
of course, i could make my own protocol, but the goal to use OSC _is_ to use OSC.
i asked #networking and they all agreed, that it is up to the application layer to define packet length (if necessary at all). the application shouldn't rely in _any_ case on tcp packeting. but this is what [unpackOSC] currently does. the only fix i can see is making [unpackOSC] stream based.
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de