[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #9022 [Pluggable transport]: Create an XMPP pluggable transport
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs