On Wed, Feb 22, 2017 at 6:26 PM, Christof Ressi <christof.ressi@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