[standards-jig] A Proposal to the DTCP/JOBS/PASS madness
jan at gondor.com
Fri Dec 13 23:37:21 UTC 2002
On Fri, Dec 13, 2002 at 04:02:47PM -0700, Dave Smith wrote:
> Huh? I don't follow your logic here, Jan. I suspect I need to clarify
> something, but I'm not sure what. What exact step do you see as
> limiting the number of connections on a single listening port?
Perhaps I missunderstood your proposal. As I understood the following
information is exchanged:
In PF2, Initiator sends a list of ip/port combinations it may be
In PF3, target connects to one of these ports, and in PF4 it tells to
the initiator to which of these ip/port combinations it connected. [X]
If the initiator started more than one connection at the same time, and
is listening for all of them on the same port, he'll get several
connections, but how should he know which one belongs to a given target?
A given TCP connection is uniquely described by source port, source ip,
destination port and destination ip. For all these connections,
destination port and destination ip are the same, while source port and
source ip are only known to 'Initiator' (who is the one accepting these
TCP connections). As the 'Targets' only know destination port and
destination ip, but not source port and ip (reliably), they can't tell them
to the 'Initiator'. So I don't see how this could work.
[X] I'm not sure if I got that correct. You may have meant that
target tells to the initiator his own ip and port he used for the TCP
connection. But that would not work, because if target is behind NAT,
he does not know the ip or port the initator would see.
> As for HTTP, I'm fine if we want to use that for doing file transfer
> over the negotiated connection, but I want to make it clear that
> negotiating the connection itself will not require HTTP (or any other
I perfectly agree that this is a worthy goal. Not sure if it can be
Let me list a few features such a protocol should provide, in my
opinion. I probably missed some, but please let me know if you don't
agree with these.
- provide a transparent, bidirectional, asynchronous channel
- use a direct connection if possible
(try connecting in both directions to work around
NAT/firewall on one side of the connection)
- do not demand more than one listening port for several
- do not invent new protocols where existing ones are suitable
- offer or allow for easy integration of some kind of proxy support
More information about the Standards