[dcc2] Other comments

[myndzi]

This is getting really complex. I've been looking at the Network and
Transport options, along with how to publish available port ranges.
There's no easy way around it. Any given range of available ports is
going to be specific to a combination of both layers. Which means if
you initially specify available listening ports you will have to
provide X*Y different ones (X = number of available Network layer
options, Y = number of available Transport layer options). The only
other way around it extends the handshaking over IRC another message.

ClientA: Publish Application=IRCChat Network=IPv4,IPv6
Transport=TCP,UDP SID=Useless
ClientB: Accept IPv4=192.168.0.3 TCP CanListen Port=1024-5000,5050 SID=Useless
ClientA: Accept IPv4=192.168.0.2 MustListen Port=3700-3710 SID=Useless
ClientB: Accept Port=3703 SID=Useless
ClientA: GoAhead SID=Useless

I really like the way this looks, with the exception of the duplicate
'Accept' messages and the fact that it is 4 messages long. If I could
specify port possibilities in the Publish message it could be
shortened to 2-3 messages instead of 3-4, but would look something
like this:

ClientA: Publish Application=IRCChat IPv4=TCP:1024-5000,5050;UDP:1234
IPv6=TCP:1010-1050

Or similar. It's fairly hard to make it look nice.

Other options along this line:

ClientA: Publish Application=IRCChat Network=IPv4,IPv6
Transport=TCP,UDP SID=Useless
ClientB: Accept TCP IPv4=192.168.0.3 TCP CanListen Port=1024-5000,5050
SID=Useless
ClientA: Accept Port=1040 SID=Useless
ClientB: GoAhead SID=Useless

ClientA: Publish Application=IRCChat Network=IPv4 Transport=TCP SID=Useless
ClientB: Accept TCP IPv4=192.168.0.3 TCP WillListen Port=1030 SID=Useless
(ClientA connects) -or-
ClientA: Accept MustListen Port=1040-1080 SID=Useless
ClientB: Accept Port=1050 SID=Useless
ClientA: GoAhead SID=Useless

This last illustrates an idea where a client attempts to guess at an
acceptible setting without further negotiation. If it IS acceptible,
the other client can immediately connect, but if not, the listening
socket is closed upon receipt of further handshaking.

This concept can be applied further; the initiating client could
indeed specify a default/preferred Network, Trasport, Port
combination, and open a listening socket (just like traditional DCC)
pending further handshaking or a connection, thus reducing the
possible messages in a well-configured system to 1. I think it would
be an excellent idea for each side to open a listening socket (if at
all possible) and provide the information required to connect to it
with each refinement of the options in negotiation. This helps to get
rid of the need for a single 'GoAhead' message, and allows the
protocol to offer both a subset of available choices and a default
choice that can be used to complete the connection as soon as
possible.

Note that in these examples I remove all redundant information from
the messages; each message serves only to refine, clarify, or correct
a previously received one.

Also notice the SID I used; I came to the conclusion recently that SID
is mostly an unneeded field. Its only application lies in preventing
confusion between concurrent DCC2 negotiations of the same Application
type, and it occurs to me that it is not a very necessary thing for
said negotiations to happen in parallel. In fact, should one fail, the
other won't likely fare any better, with the exception of a manually
denied connection on the part of the remote client.

I have also noticed that it would be useful to have a specifically
designated order to the tokens. Apptokens I believe should come after
all the connection tokens and there should be a designated marker for
this. Application= would be an excellent choice, since it is required
and also would serve as an appropriate 'segue'. Apptokens only need to
be transmitted with the Publish message, as they either provide extra
data for use in deciding whether or not to accept the connection, or
provide extra data for use once the connection is established.

SID could become optional (or required in an instance where you are
trying to initiate another DCC2 connection with a user which you
already have one pending to).

-myndzi

P.S. When does anything get done around here? There was some
discussion following my last large post, but I never heard whether any
of it was to be used, any changes to be made, any progress at all, in
fact. And the list has been silent for over a month, too!

Perhaps I shall just implement my own script along these lines as best
I see fit, and wait to see whether it is worth molding it into
compliance if anything comes of this site.