[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:89 asn]:
> Replying to [comment:79 feynman]:
> > Replying to [comment:71 asn]:
> > > Also, do you know what is this error:
> > > {{{
> > > WARNING:root:<message xmlns="jabber:client"
to="blabla@xxxxxxxxx/DDA289DC" type="error"
from="wowowowow@xxxxxxxxx"><connect
xmlns="hexchat:connect"><local_ip>127.0.0.1</local_ip><local_port>60776</local_port><remote_ip>32.1.35.12</remote_ip><remote_port>6061</remote_port><aliases>blabla@xxxxxxxxx/DDA289DC</aliases></connect><error
code="503" type="cancel"><service-unavailable
xmlns="urn:ietf:params:xml:ns:xmpp-stanzas" /></error></message>
> > > }}}
> > >
> > > It appeared on my client-side hexchat. On the client-side I used
blabla@xxxxxxxxx, and on the server-side I used wowowowow@xxxxxxxxxx I
seem to remember you talking about service-unavailable errors.
> >
> > I just realized you set up your client to initiate connections to a
gmail account. That will not work unless the client is on the servers's
contact list. You can still use gmail, just not for initiating
connections. You need to have your client run like this:
> >
>
> Ugh, I see.
>
> Hm, what do you think is going to be the workflow of users who need to
get an XMPP account to use with hexchat? If our server-side hexchat bot is
a @gmail.com JID, how are users going to create non-gmail JIDs? And how do
they connect with them to Gtalk's servers?
>
The server-side hexchat bot can have one or more @gmail.com JIDs, but it
needs to have at least one that is not gmail. The clients can then
initiate connections to the non-gmail account with any type of account
they like (gmail or not). When the server replies, it will send a subset
of all the JIDs it has logged in with. The client can then send data
and/or disconnect requests to any of these JIDs.
The server keeps track of which JIDs it sent for which connection, and
only sends messages from one of the JIDs it sent during the connection
phase.
Keep in mind that the client also sends a list of JIDs during the
connection phase and keeps track of them in the same way the server does.
Here is how it works:
1. Client sends connection request with a subset of all the JIDs it is
using. Call this set "client JIDs".
2. Server sends a connect_ack. If the connection was successful, this
includes a subset of all the JIDs it is using. Call this set "server
JIDs".
3. When the client wants to send data, it sends a message from an element
of "client JIDs" to an element of "server JIDs". When the server wants to
send data, it sends a message from an element of "server JIDs" to an
element of "client JIDs".
Clients and servers can send messages to arbitrary JIDs after the
connection is established because "client JIDs" and "server JIDs" are full
JIDs that include resources. Full JIDs are of the form
user@server/resource. Resources are sometimes assigned randomly (even if
you request one)--as is the case for gmail.
You cannot send an IQ stanza to a JID of the form user@server (i.e.
without the resource) but you can send a message stanza to a JID without a
resource. That is how clients initiate connections--at least the first
time. After it gets a response, it adds the responding JID to a dict that
keeps track of possible full JIDs to send connection requests to. From
then on, it sends connection requests via IQ--at least until it gets an
error. When it gets an error, it deletes the JID from its dict.
This all works fine for everything but gmail. You can only send messages
to gmail JIDs without resources if you are on that JID's contact list. I
found no way around that problem, so you cannot initiate connections to
gmail accounts. Period.
> Also, if users want to have N aliases (to increase their speed), they
also need to create N JIDs, right?
Sort of. I found you can log into many accounts about 20 times from the
same IP address before it refuses the connection. Here is a list of
servers that let you login at least 100 times before refusing the
connection:
https://trac.torproject.org/projects/tor/ticket/9022?replyto=89#comment:84
Some of those servers are very slow, but the jabber.* ones seem fine.
You can get away with logging into the same account multiple times because
chat servers give you a random resource by default--thus giving you a
unique full JID of the form user@server/resource--which is what you are
going to send data to anyway.
Note that messages sent to a JID without a resource will be sent to all
JIDs of that form. So a message sent to user@server will go to everyone
logged into user@server--regardless of their resource. I have already
implemented code that guarantees only one of those resources will actually
execute the connection process.
You can specify the number of times to login to each JID with the
--num_logins option. The default is 1.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/9022#comment:90>
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