[PD] tcpclient sending more than 1 send at once

[Roman Haefeli]

On Sun, 2008-09-07 at 12:23 -0400, Martin Peach wrote:
> Enrique Erne wrote:
> > hi martin and the list
> > 
> > if i send [send 11, send 22, send 33, send 44, send 55(
> > to [tcpclient] the [tcpserver] prints
> > 
> > receive: 11 22 33 44 55
> > 
> > actually i expected to get 5 messages back. is this a bug or am i wrong?
> 
> It's unanticipated behaviour I guess...it also happens if you send the 
> values as separate messages with a single bang. If you put a chain of 
> massages separated by [delay]s you can find the shortest delay that 
> sends them all separately.
> I find that I need a delay of at least 8ms between messages for them to 
> be transmitted separately. It's up to the implementation of TCP in the 
> machine to decide when to send a packet. Probably UDP would send them 
> all individually.

yo.. i would say, that it is not only unanticipated behaviour, but a
bug, either in [tcpclient]/[tcpserver] or [unpackOSC]. from what i
understand, it is a misconcept of [unpackOSC].

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


roman




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