[dcc2] Other comments

[Jeremy Iverson]

Probably just more confusion here, sorry. I don't mean "application"
as in IRC client, but "application" as in protocol. That is, I think
the main DCC2 File Transfer protocol should only allow TCP: this will
keep things simpler, which is very important. If somebody really wants
it, they can work on a UDP File Transfer protocol also, but it will be
a separate protocol. An IRC client could handle negotiation
seamlessly, because the connection negotiation protocol will allow
both TCP and UDP.

Otherwise, what should be a relatively simple document describing the
File Transfer protocol will also contain a standard that re-implements
"TCP" over UDP. If somebody wants to do that, it is better to keep it
as a separate document.

Jeremy


-----Original Message-----
From: dcc2-bounces at dcc2.org [mailto:dcc2-bounces at dcc2.org] On Behalf
Of myndzi
Sent: Tuesday, June 29, 2004 2:17 AM
To: DCC2 Working Group List
Subject: Re: [dcc2] Other comments

> If they can't maintain a TCP connection, how would they stay on IRC?
> Or do much of anything on the Internet, really.

>From past experience with NAT, it's more like "can't maintain an
*idle* TCP connection". As data goes outwards the timeout on the NAT
table is refreshed. UDP has a longer timeout generally because it does
not have any specific means of signifying and end to transmissions
(and therefore no further need of a NAT table entry).

> However, each DCC2 application protocol should pick either TCP or
UDP; 
> only one.

Why should such a restriction be in place? There's no need for it. If
it makes sense to only support one of the two, any application
designed to use DCC2 can simply use that one and only that one. If an
application wants to use either or both, there's no reason for us to
say nay...

-myndzi
_______________________________________________
dcc2 mailing list
dcc2 at dcc2.org
http://six.pairlist.net/mailman/listinfo/dcc2