[tor-bugs] #9022 [Pluggable transport]: Create an XMPP pluggable transport

[Tor Bug Tracker & Wiki]

#9022: Create an XMPP pluggable transport
---------------------------------+------------------------------------------
 Reporter:  asn                  |          Owner:  feynman 
     Type:  task                 |         Status:  accepted
 Priority:  normal               |      Milestone:          
Component:  Pluggable transport  |        Version:          
 Keywords:                       |         Parent:          
   Points:                       |   Actualpoints:          
---------------------------------+------------------------------------------

Comment(by feynman):

 Replying to [comment:49 asn]:
 > Replying to [comment:48 feynman]:
 > > I recently discovered that the caching and delivery confirmation were
 doing more harm than good. I think they were simply using too much
 bandwidth. It seems that by spawning a new thread for closing a socket and
 acquiring a lock that blocks the reading of other sockets, I could greatly
 improve the speed. It is still far from ideal, but I can usually get
 through a couple of minutes of low quality youtube videos at this point
 (even with a very slow internet connection).
 > >
 >
 > Ah. I see.
 >
 > Have you also looked at whether compression actually helps the
 transport? It might just be wasting CPU cycles because of the TLS layer
 being encrypted.
 >

 You might be right. I can take out the compression. However, I do not
 think it will help the speed because I have it set to send out messages
 once a second. I do not think it takes more than a second to compress
 data.

 > > The code and protocol specs are updated. The old code is stored in the
 misc directory of the git repository.
 > >
 > > Unfortunately, using more than one JID is still very unreliable. I am
 beginning to think that rransom was on the right track in thinking that
 the messages were getting reordered--especially since I am no longer
 verifying anything with IDs. Youtube pages load when using more than one
 JID, but the video itself never plays (despite the loading bar swiftly
 moving across the screen).
 > >
 >
 > Hm, I see.
 > This is not fun. A deployed hexchat would probably need to use different
 JIDs on the client and the server.
 >

 I might be able to do distribute connections between different JIDs, but
 that will not guarantee the load is evenly distributed between JIDs (since
 some connections could exchange more data than others).

 I might be able to exchange data with multiple JIDs per connection by
 giving each message an incremental ID and letting the client order them
 appropriately. I suppose I should try this.

 > BTW, have you tried using hexchat with Tor? Does it work? Is that how
 you do testing?
 >


 I have not tried hexchat with Tor. I will have physical access to my
 desktop (which has Tor) tomorrow. I will begin testing with Tor then.

 > Finally, the main problem with this transport seems to be Google rate-
 limiting their servers. I'm not sure what to do about this, and whether we
 can work around their throttling. After all, if they don't want hexchat to
 work on their servers, they can rate-limit them even more. Hm.

 As for Google rate-limiting their servers, they probably chose their
 current rate-limit based on what they think their servers can handle (or
 at least what they want their servers to handle). As long as hexchat stays
 under their data limit, they should not have a problem with it (at least
 not because of the amount of data being exchanged). I have the maximum
 number of bytes a socket can read at once calculated so that the buffer
 will not contain more than 2^17 bytes when hexchat sends a message. 2^17
 bytes seems to be the maximum number of bytes I can send at once before
 Google disconnects me. If I leave the throttle rate at one second, that
 comes out to be 131kb/s--which is a very slow but still bearable internet
 access.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/9022#comment:50>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online