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.h...
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