RE: [dsdp-tcf-dev] Applicability of TCF agent for remote tracing

["Burton, Felix" <Felix.Burton@xxxxxxxxxxxxx>]

Hi Michael,

> -----Original Message-----
> From: dsdp-tcf-dev-bounces@xxxxxxxxxxx [mailto:dsdp-tcf-dev-
> bounces@xxxxxxxxxxx] On Behalf Of Michael Sills-Lavoie
> Sent: Monday, May 25, 2009 6:33 AM
...
> > Correct, it is separate from zero copy.  It provides a general
> purpose
> > way of streaming data over TCF.  As Eugene pointed out it would be
> > fairly easy to do a general enhancement to the TCF channel stream to
> > allow zero copy of the data.
> 
> What would you suggest in order to implement zero copy transfer? How
> would you do it?

The way Eugene and I discussed how to implement zero copy data transfer
is to:

1) Enhance OutputStream interface in to support an additional function
to write a block of data to the channel.

2) Enhance channel_tcp.c to implement the block write function such that
it adds it prefixes the block with a marker specifying the size of the
block so no escaping is necessary on the block.  This way the whole
block can be given to the OS in a single operation.  In the case of
Linux, the write is going to copy the data from user space to system
space, but for other OSes a true zero copy might be used.

3) Extend JSON to add ways to encode binary data instead of using a
base64 encoded strings.  For zero copy we need to know how many bytes
will follow, but I would also add the capability to encode compressed
binary data of different formats.

I believe this should cover it for the sending side which I believe it
the primary concern, right?

Of course these are non-backwards compatible changes, so we need to have
a way for peers to negotiate support for this.  The solution we have
discussed for this is to add a service name which indicates the TCF
protocol version, e.g. "tcf-2". If both peers announce this service,
then the new TCP channel marker and JSON extensions can be used,
otherwise the implementation would fall back to non-zero copy mode.

Thoughts?
Felix