Just make up a code like NUMBER-STUFF, and add --code= to the
send-text/send-file command. Also don't use tab-completion on the
codewords part of the receiving side, unless you stuck to the even/odd
PGP wordlist. (tab still works for the channel-id).
Now the server allocates a channel randomly from set of available ids
with the shortest possible length. So concurrency=1 will always yield a
channel-id between 1 and 9 (inclusive). If we have 9 simultaneous
sessions, we'll start allocating channels from 10 to 99. 100
simultaneous connections kicks us into the 100-999 bucket, etc.
This is a proxy for the other client's version, and encourages both
sides to upgrade to the current version each time the server is
upgraded (which will be once per release).
To be useful, both sides must add -v. If the sender uses -v but the
receiver doesn't, the receiver won't show the verification string, so
the sender can't compare it to anything (and must either abort the
transfer or accept it blindly). Maybe the receiver should show the
verification string unconditionally. Maybe the sender should
indicate (in unprotected plaintext, along with the PAKE message) whether
the receiver should show it or not.
We used to use twisted.python.usage.Options, hence we depended upon
Twisted. Now we depend upon "argparse" instead, which is in the py2.7
stdlib (and on pypi for 2.6). This package will still (eventually)
provide Twisted support, but applications which need it will already
express a dependency on twisted themselves, so by removing the
dependency here, we make life easier for applications that don't use it.
Applications should feel free to pass wormhole.const.RENDEZVOUS_RELAY
here, but I figure it should be clear that you're using a public service
that's hosted *somewhere* external.
This fixes the situation where you start the receiver first, then start
the sender, then you hit TAB on the receiver.
This somewhat improves the situation where you start the receiver first,
hit TAB (getting nothing), then start the sender, then hit TAB on the
receiver again. The second TAB will list the channel-ids, but won't
insert the only one as it's supposed to. You must type something (which
you can erase) and then hit TAB again to get a unique channel-id
inserted. But at least you can tell which one to type.
The first TAB runs the completer with readline.get_completion_type()
equal to 9=TAB=try-to-insert. The second (and subsequent) TABs use
63=?=list-matches, and it won't go back to 9 until you type something.
If all the direct hints resulted in timeouts (e.g. they were to bad IP
addresses where connections just hang), the relay connection would fail.
The establish_connection() function had the same TIMEOUT as the
direct-hint connector, so it would give up just before the relay
connection was initiated.
