[Telepathy] Spec for file-transfer and tubes

Thu Apr 12 11:09:37 PDT 2007

Comments, anyone?

man, 02 04 2007 kl. 20:50 -0700, skrev Mads Chr. Olesen:
> Hi Robert!
> 
> I have tried to sketch up the following, following your opinion (which I
> have come to agree with ;-) ):
>  - Use local Unix sockets for all data transfer (bye IOStream, TCP
> sockets)
>  - A remote CM will be supported by some proxy
>  - If we have a legacy application (vnc), the wrapper for it will have
> to implement TCP <-> Unix socket proxying. On the listening side, the
> wrapper will connect to both the TCP (provided by vncserver) and the
> Unix socket (provided by the CM). On the connecting side, the wrapper
> will listen for an incoming TCP connection (from vncviewer) and connect
> to a local Unix socket (provided by the CM).
> 
> I have drawn this up for file transfers (using the same general
> structure as for Tubes). Darcs branch at
> http://www.cs.aau.dk/~mchro/telepathy-spec.filetranfer/
> 
> I have some remaining issues, reflected by TODOs:
>  - Does a file transfer to a room make sense? I can imagine some
> broadcast way of implementing it, e.g. for LANs, but is it practical?
> Should it just be left out?
>  - Which common bits of information do we have about a file? MD5-sum,
> SHA1-hash, thumbnail?
>  - Is the wording for the socket authentication correct? I borrowed it
> from the D-Bus spec. How does it work on the receiving end of the NUL
> byte?
> 
> fre, 23 03 2007 kl. 03:11 +0000, skrev Robert McQueen:
> > Mads Chr. Olesen wrote:
> > > man, 19 03 2007 kl. 17:08 +0000, skrev Dafydd Harries:
> > >> - 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.
> > 
> > This question was based on the idea that we'd have some kind of
> > file/stream object which would initially appear on the starter bus (ie
> > the one you use to talk to the CM usually) in order to meet the "bus is
> > forwarded to a remote CM" use-case. If the client is local to the CM, a
> > local socket makes sense, so I agree that the private bus stuff seems a
> > bit redundant.
> > 
> > Even if the CM is remote, it's likely some proxy will exist and can
> > understand Telepathy, so this proxy could arrange to forward the sockets
> > for you (imagining something with libssh on the client end, it could
> > make a new ssh channels for every file you transferred or tube you joined).
> > 
> > >> - how should authentication work for local sockets?
> > > I suggest: Use file permissions on local sockets.
> > > Pros:
> > > - Only correct user's apps can connect
> > > Cons:
> > > - ...
> > 
> > Unfortunately chmodding Unix sockets is Linux-specific. To protect Unix
> > sockets on other architectures using permissions, you need to make
> > subdirectories which contain them, which get left behind and clutter up
> > /tmp when stuff crashes or whatever, and get you temporary file naming
> > issues. Instead D-Bus uses credential passing, where a struct describing
> > the current user is "attached" to some data (a NUL byte) and sent, via
> > the kernel verifying it's truthfulness, to the bus daemon. So anyone can
> > connect to the Unix socket, but if it's not the right local user they
> > get disconnected immediately.
> > 
> > >> - 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
> > 
> > At the moment in the tube spec we don't actually have a D-Bus object
> > which attempts to transmit the tube or file data sent/received over any
> > kind of bus (either a starter or a private bus), and as I said in the
> > first paragraph, I'm not convinced it's hugely useful to enter into that
> > complexity just for the (currently hypothetical) remote CM use case.
> > 
> > I don't understand what you mean with emulation. If a client is using
> > libtelepathy, it's coding against the Telepathy API already, so has no
> > legacy code to worry about. You don't need any emulation inside
> > libtelepathy to make a TCP socket look like a Unix socket or vice versa.
> > I don't think that makes any sense.
> > 
> > That leaves us with local Unix sockets, which we know that we can secure
> > somehow, and TCP sockets which we can't very easily. My conclusion is
> > that the CM shouldn't implement TCP sockets unless that we *really* need
> > them. For me, that would be in order to support launching a TCP legacy
> > application for use with a Tube.
> > 
> > For seperate reasons (code re-use, insulation from wire protocol,
> > multi-user semantics, etc), we've decided that rather than a normal Unix
> > socket, these non-legacy brave new Telepathy clients should talk D-Bus
> > to each other. If that's wrong or troublesome for people, we can
> > consider providing a normal Unix socket too.
> > 
> > >>  - 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.
> > 
> > Why do we need TCP connections for remote CMs? I think it's easier for
> > CMs to implement one thing, ie Unix sockets which are more useful to us
> > on local clients. The thing which connects us to the bus that the remote
> > CM is running on can also connect us to the remote CM's Unix sockets,
> > and do any converting between Unix sockets/TCP as necessary.
> > 
> > >>  - how will this work if the connection manager is not on the same
> > >> machine as
> > >>    the client?
> > > I suggest: Let's support this.
> > 
> > Let's not rule this out, but let's not make our job too complicated
> > either... :D
> > 
> > > Am I missing something? I'll try to write it up as a spec sometime soon.
> > 
> > Well, as you can see I'm in favour of D-Tubes for tubes, which is the
> > spec we've merged and started implementing, and a Unix socket for file
> > transfers. We'll need a protocol where we throw a NUL byte over the
> > socket so we can exchange credentials, and libtp can help our clients do
> > that.
> > 
> > Remote CMs can be supported by proxying these remote Unix sockets to
> > local Unix sockets somehow (which is similar to how ssh X forwarding
> > works, and how a ssh D-Bus forwarding would probably work).
> > 
> > If clients have real need for tubes which aren't D-Tubes, we can add
> > that to the spec, and re-use the file transfer Unix socket code for tube
> > Unix sockets.
> > 
> > If we have the need for exporting a legacy TCP service over a tube, we
> > can add a little API for this. Unlike transferring a file, I don't think
> > security is *hugely* important for such TCP services, because these
> > legacy TCP protocols will all have their own authentication (eg VNC) or
> > not need it (eg http).
> > 
> > I think that in my mind, the person who offered the tube would have a
> > TCP server (ie listen() somewhere) and tell the port to the CM when
> > offering the tube. Once the remote party accepts the tube, their CM
> > opens a listen() socket. Every connection to it would then result in a
> > connection being tunneled to the initiator's TCP service, much like ssh
> > -L behaves. In the case of eg VNC, the params dictionary could contain a
> > username and password, or similar.
> > 
> > How does all that sound?
> > 
> > Regards,
> > Rob
> 
> _______________________________________________
> Telepathy mailing list
> Telepathy at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/telepathy