[standards-jig] A Proposal to the DTCP/JOBS/PASS madness
jan at gondor.com
Fri Dec 13 20:17:08 UTC 2002
On Fri, Dec 13, 2002 at 11:16:52AM -0700, Ben Schumacher wrote:
> Jan Niehusmann wrote:
> | - it may take a long time to establish a connection, because the clients
> | may have to wait for a TCP connection timeout before they notice that
> | a connection is not possible.
> This is a problem shared by any protocol that tries to make a TCP
> connection, including DTCP, JOBS, etc. This is an accepted reality of
> network programming.
Here you missed the only major difference between DTCP and Dave's
suggestion. With DTCP, both sides try to connect at the same time, and
as soon as one connection succeeds, the others are aborted. We only need
to wait for a timeout once, and if it expires, the connection failed.
With Dave's protocol, first the target tries the TCP connection,
waits for the timeout, then notifies the initiator of the unsuccessful
attempt and offers a connection in the opposite direction. So even a
successful connection may have to wait for a connection timeout first,
which is unacceptable if it happens for each transfer.
In order to work around that problem, clients would need to 'cache' the
information that some connections are not possible and should not be
tried, which means additional code complication. And how should a
client notice transient connection problems?
Unfortunately, with DTCP's approach to initiate TCP connections in both
directions at the same time, there is an ambiguity if both connections
succeed. In order to resolve that ambiguity and decide which one of the
connections to use, DTCP implemented the handshake on the TCP channel.
But perhaps even that handshake may be moved over to the jabber stream?
I'll go on and try to modify JEP-0046 to match Dave's idea, perhaps we
could have best of both?
> | - a client may not know that it is firewalled, so how to decide if a
> | proxy is necessary?
> The software may not, but generally a user would be aware. In a well
> designed client, I could add an option of "always use proxy server" or
> something similar.
Right, most users would be aware of firewalls, and with a helpful error
message on a failed direct connection, even users who are not may
be hinted to try that option.
> why we feel we need to create new protocols for everything. HTTP may not
> be appropriate for IM, but it most certainly works for serving files...
> that is what the protocol was designed to do, after all.
I mostly agree. But I think we may not need a protocol at all:
A typical IM file transfer is initiated by the sender, who offers
the file via the IM protocol. In our case, some kind of jabber XML
would be sent to announce the file. In order to give the recipient
sufficient information to decide if he wants to accept the transfer, that
announcement should include filename, length, description, and perhaps
mime type, if available. At that point, all these facts are known to
the receiving client, which makes most of the HTTP protocol redundant.
We could simply send the file through the TCP connection without any
The difference to typical HTTP usage is that with HTTP, there is usually
no prior information exchange, so HTTP needs to carry all the meta
information about the transfered file.
> | Perhaps that could even be extended to allow UDP 'connections', allowing
> /me shudders.
;-) just an idea, not to be taken too serious.
More information about the Standards