[PD] tcpclient sending more than 1 send at once

[Roman Haefeli]

On Tue, 2008-09-09 at 09:17 -0400, Martin Peach wrote: 
> Roman Haefeli wrote:
> > i think, i am going to do the frame length part myself. for me the
> > problem is solved (i don't need anyone to change any code). thanks!
> > 
> 
> 
> Great! Let us know what you come up with, it should be added to the help 
> files for [packOSC] and [unpackOSC].
>
> Martin
> 

yo.. i made some abstractions based on [packOSC] and [unpackOSC], called
[packOSCstream] and [unpackOSCstream].

[packOSCstream] prepends the OSC packet/bundle length as int32 (please:
someone needs to confirm, that the format used is actually int32) to
each OSC packet/bundle.

[unpackOSCstream] separates OSC packets/bundles according to the length
given in the frame header created by [packOSCstream].

get it from:
http://romanhaefeli.net/software/pd/OSCstream.tar.gz


i think, especially [unpackOSCstream] needs thorough testing. in the few
tests i made, it was working well. however, not having a delimiter, but
having to rely on counting bytes seems a bit dangerous to me, since even
only one missed byte would cause [unpackOSCstream] to completely fail. i
wasn't able to trigger that, though. if TCP is considered robust (and i
assume, it should be considered this way), it is unlikely to happen.

potential issues:

- if several [tcpclient]s/[tcpsend]s are connected to a
[tcpserver]/[tcpreceive], the whole system fails, if one of the clients
is sending something else than an OSC packet.

- when several [tcplient]s/[tcpsend]s are sending OSC packets
simultaneously to one [tcpsever]/[tcpreceive], [unpackOSCstream] might
fail, if the incoming tcp packets are not either one or a multiple of
OSC packets long. i didn't experience it yet, but since TCP is a stream
based protocol, it should be assumed, that TCP doesn't respect OSC frame
borders at all. however, this is only a theoretical problem so far,
since i never experienced that TCP is delivering fractured OSC packets.

the only solution for a robust OSC transport i can think of, is if on
the receiver side every client gets its own [unpackOSCstream], which is
an ugly solution.

probably someone else is able to come up with a better idea.

roman


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