On Saturday 01 May 2010 16:19:10 Dario Freddi wrote: > Hello, > > I managed to implement a preliminary version of StreamTubes. There's still > a critical problem in the accept phase I cannot get over and I'd like you > to take a look as well. But one thing at a time.
Quick update: I switched using Unix sockets in IncomingTubeChannel while the problem gets settled, and everything is working nicely :) I made the sockets exchange some random text messages and printing them to stdout. Also, to demonstrate that everything is working, the sender is using a standard QTcpServer with default listening arguments, while the receiver is using, as already said, a unix socket. > > The code is in my private git repo ( > http://git.collabora.co.uk/?p=user/drf/telepathy- > qt4.git;a=shortlog;h=refs/heads/high-level-tubes ), branch > high-level-tubes. It's rebased upon the CMake branch, given that I suck at > autotools and the cmake branch will be eventually merged before my changes > get in. It features the new stream tube classes, and an example to let you > test. > > The problems: > > - I couldn't manage to demarshall the variant returned by > StreamTube.Accept into a SocketAddress* struct. After some debugging and > stuff, I'm completely clueless about the problem. Demarshalling the > variant I managed to get the address literal as a QString, but not the > port. The funny and problematic thing is that the very same thing happens > in FileTransfer channel (in which I also fixed a bug which lead to a > crash, patch upcoming), where the AcceptFile method should return the same > struct. > > - I bundled all the features into FeatureCore. > > - When accepting the tube, at the moment I'm not giving the user a choice > for the socket type. Any hints on how to do that in the API? I'd rather > not expose the bare socket type. > > That should be all for now. > > On Wednesday 28 April 2010 19:42:14 Olli Salli wrote: > > On Tue, Apr 27, 2010 at 10:44 PM, Dario Freddi <[email protected]> wrote: > > > On Tuesday 27 April 2010 21:37:59 Dario Freddi wrote: > > >> On Tuesday 27 April 2010 18:30:03 Olli Salli wrote: > > >> > On Sat, Apr 24, 2010 at 3:55 PM, Dario Freddi <[email protected]> > > wrote: > > >> > > Hello, > > >> > > > > >> > > please find attached a new version of tp-qt4 high level tubes. > > >> > > > > >> > > This time they're really high level - I tried keeping the API (and > > >> > > parameters as well) as similar as possible to tp-qt4 file > > >> > > transfers - it also features the same mean of creation by using > > >> > > TubeChannelCreationProperties. > > >> > > > >> > [snip] > > >> > > > >> > The device attribute I'm not really getting - why would an app > > >> > requesting a tube have a relevant IO device already? Connecting > > >> > sockets to sockets when implementing a "tunneling" application? I > > >> > think this is cargo-cult from FT, where one provides the file to > > >> > send by providing a QIODevice - this is an abstraction for giving > > >> > it an existing "file" of any kind. However, the use case here is > > >> > completely different. One should consider setting up an outgoing > > >> > stream tube analogous to connecting a TCP socket from a client to a > > >> > server for communication. One should be able to easily replace the > > >> > TCP connect logic in a networked app by offering a d-bus tube with > > >> > the remaining app logic remaining the same (using a QIODevice for > > >> > communication, this time it being the tube instead of a QTcpSocket > > >> > set up by the application). > > > > Sorry, I was totally talking crap here :( In reality, offering a > > stream tube is equivalent to starting to listen on a socket and > > "advertising" "I'm listening right here", not connecting. You seem to > > be well aware of this though, hope I didn't confuse you too much. > > Still, I wouldn't like Offer to take QIODevices, as a generic IO > > device (think a file or somesuch) can't be exported, and it's actually > > QTcpServer and QLocalServer which don't derive from QIODevice that > > correspond to listening sockets. You could offer QTcpServer and > > QLocalServer taking overloads though. It's easy to extract the address > > from those. Still, you need the bare address version too, as the > > socket isn't both a qt socket AND in the same process in all cases. > > > > >> As suggested, I changed the offer function in > > >> OutgoingStreamTubeChannel to: > > >> > > >> PendingIODevice *offerTube(const QString &name, const QHostAddress > > >> &address, const QVariantMap ¶meters); > > > > > > Of course I meant: > > > > > > PendingIODevice *offerTube(const QHostAddress &address, const > > > QVariantMap ¶meters); > > > > You don't need (actually even can't have) it returning a > > PendingIODevice since, yeah, it's exporting a socket existing > > somewhere in an address space the CM can see, NOT creating a new > > socket (except implicitly by the CM when someone accepts in the other > > end of the tube). > > > > > And in Account: > > > > > > PendingChannelRequest *createStreamTube( > > > > > > const ContactPtr &contact, > > > const QString &serviceName, > > > const QDateTime &userActionTime = > > > > > > QDateTime::currentDateTime(), const QString &preferredHandler = > > > QString()); > > > > > >> QHostAddress should already nicely encapsulate the needed logic for > > >> address_type+address, I would appreciate if one of you could confirm > > >> that. > > > > QHostAddress is excellent for exporting TCP sockets, however we should > > also expose unix sockets as supported by the spec. In addition to the > > possible aforementioned QLocalServer taking overload this could be > > simply an overload taking a const QString &socketName instead of the > > QHostAddress. QString supports embedded NUL bytes so the abstract > > socket case would be supported too. > > > > >> I am wondering if I should also expose socket_access_control: in case > > >> it's not needed, what's a sensible default? I see in FT Localhost is > > >> always used, but I'm wondering if there are some use cases I'm not > > >> considering here. > > > > The socket used in FT is just a temporary socket created exclusively > > for transferring the file in question between the CM and the client, > > enabling its type and access control to be "negotiated" by the client > > and CM freely. TpQt4 FT uses IPv4 as the address type because the spec > > requires all CMs to support it. For FT, Localhost access control is > > sufficient for most cases, since the client and CM are running on the > > same session bus, which usually means they're running on the same host > > too. > > > > For stream tubes however, the socket to export can be arbitrary > > depending on the server application, and it's not necessarily > > exclusively created to be exported over a Tube. It doesn't even have > > to be on the same host, actually... So you do need to support > > specifying the access control, but for most use cases Localhost should > > be alright so it'd make sense to have it as a default parameter. One > > thing buggering me is that the new stream tube D-Bus API doesn't > > actually seem to have a way to provide the address for Port type > > access control (old tubes api had a "access control parameter" variant > > for this purpose) - so we really can't sensibly support anything other > > than Localhost required or not and Credentials required or not. > > > > So I think we're down to at least two overloads (one taking a > > QHostAddress and the other taking a QString), possibly four > > (additional ones taking QTcpServer and QLocalServer). Every method > > should include an accessControl = Localhost parameter, and none should > > return a IO device. Does this sound sensible this time around? ;) -- ------------------- Dario Freddi KDE Developer GPG Key Signature: 511A9A3B
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ telepathy mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/telepathy
