[PD] tcpclient sending more than 1 send at once

[Martin Peach]

Roman Haefeli wrote:

> please correct me, if interprete things the wrong way, but from my tests
> [tcp*] and [unpackOSC] don't work 'well' together. [tcp*] seem to not
> know anything about messages, they simply treat any incoming data as a
> stream (without any concept of delimiters). depending on how quickly you
> send messages to the sending object, the receiving object makes one or
> more pd messages out of it (this most likely happens on the tcp layer,
> where pd/[tcp*] assumingly doesn't have any influence on). [unpackOSC]
> on the other hand is 'stream agnostic', it only accepts input as
> messages with correct number of elements. messages that are longer than
> one OSC packet are truncated to exactly one OSC packet, while the rest
> is silently ignored. if one message to [unpackOSC] is too short,
> [unpackOSC] drops an error:
> 
> unpackOSC: packet size (19) not a multiple of 4 bytes: dropping packet
> 
> from what i can tell, [tcp*] and [unpackOSC] are incompatible, since the
> former are 'message agnostic' and the latter is 'stream agnostic'.
> 
> if i am right about this, i really hope, that it could be fixed in some
> way. my suggestion would be to change [unpackOSC] in way, so that it
> treats incoming messages as a [stream] (in other words: it would
> completely disregard messages and always give an output, as soon as an
> OSC packet is completed).
> 
> this is no problem as long as you use [unpackOSC] together with [udp*],
> since then you would expect some messages to drop. but when going the
> tcp route, you'd expect completeness on the receiving side. currently it
> is not possible to rely on this, as this little test shows:
> 
> [send /test 1, send /best 2(
> |
> [packOSC]
> |
> [tcpclient]
> 
> [tcpserver]
> |
> [unpackOSC]
> |
> [print]
> 
> it prints:
> 
> /test 1
> 
> 

Actually the proper way to deal with sending multiple OSC messages at 
the same time is to put them into a bundle. Then [unpackOSC] will unpack 
them and output them in sequence.


Martin