[PD] socket object?

[Roman Haefeli]

On Thu, 2012-02-16 at 17:01 -0500, Martin Peach wrote:
> On 2012-02-16 16:38, Roman Haefeli wrote:
> > Hi Martin
> >
> > On Thu, 2012-02-16 at 19:53 +0100, IOhannes m zmölnig wrote:
> >> On 02/16/12 19:39, Martin Peach wrote:
> >>> As I understood it, the OS's tcp/ip stack will take care of putting tcp
> >>> packets back together, the application will receive complete messages
> >>> unless they are bigger than an IP packet (~65k). Only if the sender is
> >>> dribbling out partial messages would that be a problem. Fragmentation is
> >>> more relevant to serial communications, where a packet arrives one byte
> >>> at a time with no obvious boundaries unless you use SLIP, or a serial
> >>> wireless link where bytes may be lost. TCP just discards broken packets.
> >
> > I think, this is a misconception. As IOhannes pointed out, TCP is a
> > _serial_ protocol. No assumption can be made about the underlying
> > transport. You don't know if an IP packet size can be guaranteed trough
> > the whole path. It might well be, that the at some point the IP packets
> > are broken down in smaller packets. Also the opposite happens easily:
> > When the application sends many small chunks in short time, the network
> > stack might glue them together and put them into one IP packet. There is
> > no way you can take them apart on the receiving side.
> > Also, the application protocols I know that are built on-top of TCP use
> > all some kind of delimiting mechanism (think of HTTP, SMTP, IRC, etc). I
> > don't know of any protocol, that relies on the chunks keeping their size
> > over transport for delimiting messages. Using TCP chunks as a way of
> > delimiting is wrong and should not be promoted (as it is done by the
> > [mrpeach/tcp*] classes).
> >
> 
> The [mrpeach/tcp*] classes don't make any assumptions about content, 
> they just output lists of floats as they arrive. It seems more efficient 
> to do that than to output individual floats. Whatever is handling the 
> output of a [tcp*] should be able to decide for itself where the packet 
> boundaries are. I don't assume that a list is necessarily the same 
> length as a packet.

In practice, it only makes senses to deal with lists instead of single
numbers (performance wise) when you don't need to look at the content of
the data at all, for instance when you just proxy it to some other
receiver (file, comport, netsocket, etc.).

However, whenever you need to parse the protocol, you need to serialize
the data anyway (since the list length doesn't give you any useful
information) and doing that in user-space is much slower than the
external doing it on its own. This is the is the case I consider the
common one. This is why I still think, that the output shouldn't be
lists, but a stream of floats. 

Roman