[PD] tcpclient sending more than 1 send at once

[Roman Haefeli]

On Mon, 2008-09-08 at 09:08 -0400, Martin Peach wrote:
> 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.

yeah, i agree. but what is with messages, that follow each other with
less than 8ms and more than 0ms? there is no solution for that. from a
user perspective, you don't always know beforehand in what time
intervals OSC packets are going to be sent. 
to cover any case, the only proper solution i can think of is, that
[unpackOSC] works stream based and not message based.

may i ask, if there are plans to change  [unpackOSC]? the reason i ask
is, that i am currently stuck with the development of netpd because of
this. if it stays as it is, i'll bury my plans to switch netpd to OSC.

roman



	
		
___________________________________________________________ 
Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de