[JDEV] Q: oob and direct P2P communications

[Jens Alfke]

On Thursday, March 29, 2001, at 12:43 AM, Daniel Veillard 
<veillard at redhat.com> wrote:

> Of course this is completely dependant on the actual firewall setup,
> and also never forget that running HTTP on a port different than 80
> is usually extremely simple ;-)

I don't know of any kind of firewall that allows incoming connections to 
arbitrary hosts inside. Usually this has to be configured on a 
host-by-host basis, and no network admin I've ever met would take kindly 
to doing this just so you could swap files with your buddies.

As for NAT, the problem is even worse since the machines inside don't 
even have real addresses. The best you could do here is configure the 
NAT server to map a particular incoming port to a specific machine on 
the network; not very useful for us.

> Scaling, since the server may have to keep them around and somewhat
> acts as the bottleneck for the number of client you can support at once

There's no need to guarantee that file transfers will be stored for 
offline users. I think it would be perfectly appropriate if such a 
message were rejected if the recipient were offline.

I'm not convinced file transfers are going to bring servers to their 
knees. SMTP servers hold up fairly well. And the rest of Jabber is 
pretty low-bandwidth. Moreover, ICQ and Yahoo manage to support zillions 
of users while having protocols that send file transfers through the 
server when necessary.

> Welcome to reinventing TCP on top of a different transport protocol.

Not exactly. Jabber presumably provides reliable delivery, and 
reassembling a file from out of order pieces is trivial.

So my assertion remains: The oob specification in itself is inadequate 
for the real world: very large numbers of hosts will not be able to 
connect without some kind of help from a server. I think that making oob 
and file transfer functional takes precedence over abstract 
architectural goals like keeping server traffic to a minimum. Given that 
the server may have to get involved, the question becomes: how is this 
best to be done?

Here's another modest proposal: a lightweight relaying mechanism that 
creates a virtual socket between the two clients. In the worst case, 
each client opens a new socket to its local server and the two servers 
(which are known to be able to connect directly) open a socket between 
them to relay the traffic.

--Jens
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 2505 bytes
Desc: not available
URL: <https://www.jabber.org/jdev/attachments/20010329/e7ac86a8/attachment-0002.bin>