[dcc2] Other comments

[Szymon Stefanek]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Saturday 26 June 2004 21:21, myndzi wrote:
> Perhaps you didn't read my other "big" post. The answer is, the remote
> party needs to know what port ranges you are _willing_ to listen on.
> This can be a subset of those you are actually _able_ to. The reason
> for this is to resolve firewall issues better, so that both sides can
> check their available outgoing ports versus a selection of incoming
> ports and decide on one that works for both of them.

Ok, I understand the problem: this is a huge issue.
First of all: how do you determine the ports you're going to (you are able to 
or you're willing to) listen on ? This is an information that you can't know 
exactly unless you effectively try the listen() call on that ports.
Sure, the user can provide you summary informations, but if a port is already 
occupied by some daemon you will not be able to use it again.
Also, ports in range 1-1024 are privileged ports on most UNIX-like systems:
you will not be able to listen on them unless you're the root user. (In this 
picture the connection on port 433 is always going to fail).

>
> > But if one succeeds then the other could probably too :)
> > Sending two files at once (with single-file transfer) is and will remain
> > a common case.
>
> Sure, but you may as well send them in serial.

Sure you can, but if we're using the SID then the assertion above remains 
unchanged, if we're not using it then the assertion above must be changed to 
"You MUST send them in serial".

> I didn't say everything should be ordered, but I just would like to
> see the tokens split into the two disparate groups that they are. How
> is it harder on parsing to assume that everything up to a certain
> point are connection tokens, and the rest are application tokens (to
> be passed on to the application using the connection)?

Can't you just parse all the parameters, put them in a <name>-><value> 
hashtable and then lookup them by name ?

> Have you actually tried to write something that complies to this crap yet?
> :P

Not yet, I'm still trying to finish the draft that tries to describe correctly 
the CTCP specification that DCC2 should be based on :D


- -- 

Szymon Stefanek

- ------------------------------------------------------------------------------
- -
- - When least expected... cloud connected.
- -
- ------------------------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA3ryvRu+qkQYW8QERAq1rAJ4kQKqVWcEqxWW3hjiDKP6SWmqsAgCcDB1U
v1h7cBY3hPsZT/in9eSynrc=
=z61R
-----END PGP SIGNATURE-----