[Telepathy] Spec for file-transfer and tubes

[Robert McQueen]

Mads Chr. Olesen wrote:
> Comments, anyone?

Examining and commenting on this is on my todo list, but I've been
travelling and on holiday last week and haven't quite caught up on stuff
now I'm back in the office. Thanks for your input, you're not
forgotten... :)

Regards,
Rob

> 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