[Telepathy] Spec for file-transfer and tubes

[Mads Chr. Olesen]

As I see it, we want to support two types of applications:
 - Future applications using D-Bus for IPC with a remote app
 - Legacy applications, e.g. VNC, using TCP for communication

We want a system that is:
 - Secure (as much as possible)
 - Efficient
 - Able to run the CM on one machine and client on another

I have made some benchmarks with socat and netperf, to find out how big
a performance hit it is to put a wrapper in between. The conclusion:
Doing netperf <=> netserver performs just as good as doing netperf <=>
socat <=> netserver. In fact, _no_ performance hit was visible wrt.
throughput and latency, even with 8 socat's between netperf and
netserver.
The bottomline: doing conversions on the local machine, e.g. from TCP
socket to a Unix Socket, is virtually free...

With this in mind, I will try to outline my opinion on the different
points.

man, 19 03 2007 kl. 17:08 +0000, skrev Dafydd Harries:
> I've been discussing this with Rob and Simon, and we got a bit bogged
> down in
> various questions:
> 
> - should we offer a private bus for data transfer?
I suggest: I'm not sure this is necessary. A local socket provides the
same functionality, and is much easier/as easy to use for clients.

> - how should authentication work for local sockets?
I suggest: Use file permissions on local sockets.
Pros:
- Only correct user's apps can connect
Cons:
- ...

> - is IOStream suitably general for file transfers and tubes?
I suggest: Yes. The CM should implement at least TCP-sockets, and e.g.
libtp should provide wrappers for using a local unix socket through to
the TCP-socket.
Pros:
- Provides same interface for both in the CM => code re-use
- Provides maximum flexibility for clients
Cons:
- libtp needs to have extra code for emulating the client's requested
method

>  - do we really need local UDP/TCP connections, or are local Unix
> sockets
>    sufficient?
I suggest: No, not necessarily. However, we need TCP connections for
remote CMs anyway, and can wrap a local Unix socket to a TCP-connection,
so I would say CMs must implement TCP-connections and can implement Unix
sockets.

>  - how will this work if the connection manager is not on the same
> machine as
>    the client?
I suggest: Let's support this.

=================

For the legacy client i suggest:
- The (remote) CM implements TCP-sockets
- The legacy client wrapper implements security, in cooperation with the
CM.

For the future D-Bus using client, I suggest:
- The (remote) CM implements TCP-sockets, and _can_ implement local Unix
sockets
- The CM detects (with help from cm-lib) if it is remote, and handles
this by falling back to TCP.
- Security is handled by D-Bus (I believe this is sufficient?)

If we have anything that needs a local Unix socket (I can only think of
file transfers), I suggest:
- The (remote) CM implements TCP-sockets, and _can_ implement local Unix
sockets
- libtp checks if the CM implements Unix sockets, and if so uses that
directly
- libtp provides a TCP socket <=> Unix socket wrapper, used as client
<=> Unix Socket <=> TCP socket <=> CM, and handles security with this
wrapper
- Security on the Unix socket is handled with file permissions.

Am I missing something? I'll try to write it up as a spec sometime soon.

-- 
Mads Chr. Olesen <shiyee at shiyee.dk>
shiyee.dk