[PD] tcpclient sending more than 1 send at once

[Roman Haefeli]

On Tue, 2008-09-09 at 14:56 +0200, IOhannes m zmoelnig wrote:
> Claude Heiland-Allen wrote:
> > Martin Peach wrote:
> >> The idea is to expand it to fit circumstances as they arise. I hadn't 
> >> really tried OSC over TCP, so I wasn't aware of this problem. I agree it 
> >> needs fixing, I'm just not sure of the best way at the moment. It could 
> >> be simpler to prefix the OSC packet with its length.
> > 
> > That's indeed what is recommended by the OSC specification for 
> > stream-based protocols:
> > 
> > http://www.nabble.com/Questions-wrt--OSC-implementation-details.-td1109673.html
> > 
> > But this makes it more complicated, [packOSC] and [unpackOSC] would need 
> > to know whether the data should be sent or is being received from a 
> > packet-based protocol or a stream-based protocol, to know whether to 
> > prefix the length or not.
> 
> i don't think that [packOSC] and [unpackOSC] should handle these.
> the OSC-specs say: "The underlying network that delivers an OSC packet 
> is responsible for delivering both the contents and the size to the OSC 
> application."
> [packOSC]/[unpackOSC] could be seen as the "OSC application" part, 
> whereas [tcpsend]/[tcpreceive] could be seen as the "underlying network" 
> part (or part thereof).
> 
> however, i _do not_ propose to add the length prefix to the 
> [tcpreceive]/... part, as this will make it less useable in any other 
> context.
> 
> personally i think it is a design flaw in OSC, to have stream-based 
> transmission differently from package-based transmission.
> claiming that the "underlying network" has to take care of it, is in 
> contradiction to the claim of being "transport layer independent" (but 
> then, the specs doesn't explicitely say so, and i probably just make it 
> up myself; one could also argue, that OSC does not directly build on top 
> of the transport layer and that there should be something inbetween OSC 
> and the transport layer)
> 
> i think, the sending of "plain" OSC-messages should probably have been 
> unsupported from the beginning, with eventually having a stripped down 
> "bundle" that just has the message-length.
> 
> but anyhow, OSC has been around for quite some time, it's most likely 
> useless to hope for a change.
> 
> as (imho) the re-packaging should be neither part of [unpackOSC] nor 
> [tcpreceive], i would suggest using intermediate objects that handle the 
> re-packaging of streams.
> for now, zexy's [repack] should be able to do it.
> on the long run: shouldn't Pd's [list]-family contain an 
> atom-accumulator of this kind?

why not doing it with plain pd? because it is too much processing
overhead?

as you guys mentioned, the OSC specs propose to use int32 for the frame
length. however, since pd doesn't know any integer type, not all of the
four bytes can be used. otoh, this probably isn't too bad, because
packets with more than 16777215 bytes are quite unlikely. is that
something that needs to be tought about or shouldn't one care?

roman


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