[PD] netsend/netreceive questions ...

Martin Peach chakekatzil at gmail.com
Thu Feb 23 02:39:23 CET 2017


On Wed, Feb 22, 2017 at 6:26 PM, Christof Ressi <christof.ressi at gmx.at>
wrote:

> > I believe what happens is that mrpeach/net objects output each incoming
> chunk as a whole, or spoken from Pd view as list.
> ...
> > iemnet's tcp* objects make this nature of TCP explicitly clear by
> > outputting only single bytes, a.k.a stream of bytes.
>
> You're absolutely right!
>
> The help patch for mrpeach/tcpsend is really misleading because instead of
> [packOSC] it should rather mention [packOSCstream] (which is just an
> abstraction with [packOSC]+[slipenc]). It really managed to fool me into
> thinking that OSC + TCP is possible... although via localhost, I have to
> send OSC messages with more than 4000 float args to make it break. Anyway,
> I think I never actually used OSC + TCP without SLIP encoding in a project
> (otherwise I would have gotten occasional errors from [unpackOSC]) - and I
> certainly won't in the future :-).
>
> TCP is supposed to deliver its packets in order, even if they arrive at
the interface out of order. So [tcpclient] or [tcpreceive] will always
output packets in order. TCP may also wait for more data before sending a
packet, so you could have more than one OSC message in a TCP packet if
you're sending rapidfire to the same port.
Right now, [unpackOSC] only accepts lists, which must be complete OSC
packets. I could make it accept lists, or single floats, with no output
until it has a complete packet or a definite error, although [slipdec]
already does this with less overhead (it doesn't need to keep parsing a
packet until it's complete). A problem with OSC is that the correct packet
length is unknown until after the typetag string has been read in, and
oldstyle OSC messages with no typetags are completely indeterminate.

Martin

> <https://lists.puredata.info/listinfo/pd-list>
> <https://lists.puredata.info/listinfo/pd-list>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20170222/b5744282/attachment.html>


More information about the Pd-list mailing list