[PD] tcpclient sending more than 1 send at once

Roman Haefeli reduzierer at yahoo.de
Mon Sep 8 18:32:30 CEST 2008


On Mon, 2008-09-08 at 16:18 +0000, Martin Peach wrote:
> Roman Haefeli wrote:
> >
> >Martin Peach wrote:
> > > Yes, and [unpackOSC] has no way of knowing if it is getting data from
> > > UDP or TCP so it should probably assume the worst and go for TCP. In
> > > fact, to be unbreakably robust it should assume it is getting input one
> > > byte at a time and not output anything until either an entire OSC packet
> > > has been received or the packet is not valid OSC.
> >
> >this is how i would like [unpackOSC] to behave. i don't see any other
> >way to do OSC over tcp.
> >
> 
> I think opening a bundle and putting all the simultaneous messages in it, 
> then closing the bundle and sending it, will work over tcp.
> 
> In practical terms a byte-wise [unpackOSC] would have to copy incoming bytes 
> into a buffer and repeatedly attempt to parse them as an OSC message until 
> the entire message had been received. The overhead of doing this would waste 
> a lot of cpu.
> 
> If a tcp packet always contains an integral number of OSC packets it's a 
> little easier, we just have to check for more packets in the buffer.
> 
> I would try the bundle approach first...
> 

ok.. the bundle approach works, even if messages are not sent in 0 zero
logical time, which is good.   as a workaround i will use this. however,
i still consider it a workaround, because i need to make an assumption
about what interval is needed, so that the underlying layer (tcp)
creates separate packets instead of concatenating them together. i
consider having to make this assumption not at all a proper solution,
because this time value may differ between operating systems (between
every computer, even?). so basically, it's luck whether this is going to
work or not. i don't have any influence on it as a user. 

while we are at it:
i don't see any reason, that [tcp*] are packing the incoming tcp stream
to lists of numbers, since the message format doesn't tell you anything
about how it was packaged on the sender side. wouldn't it be 'more
correct', if [tcpclient]/[tcpreceive]/[tcpserver] would drip each byte
instead of putting them into lists?

roman
  


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





More information about the Pd-list mailing list