[Telepathy] Spec for file-transfer and tubes

Mon Apr 16 09:42:27 PDT 2007

On 4/12/07, Mads Chr. Olesen <shiyee at shiyee.dk> wrote:
> 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
>
> _______________________________________________
> Telepathy mailing list
> Telepathy at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/telepathy
>

FileTransfer looks fine to me with respect to implementing in Idle with DCC.

-- 

Br,
Olli Salli