Re: [JDEV] Win client, File Transfers, invite tag..

[Jeremie <jer@jeremie.com>]

> Aha!  But we still have trouble!  In a typical situation, I have a network
> connection to a server, and it either has, or makes, network connections
> to the destination server, which has a connection to the destination user
> on that server.
> 
> I start flooding my server with messages as fast as I can, across my cable
> modem.  There is a lot of congestion in between my server and the
> destination server, so all my packets pile up on my server as it tries to
> send them to the other server.
> 
> There are three seperate TCP/IP connections involved, so if the 2nd or 3rd
> connection is slower than the 1st or 2nd, messages will pile up.

Yes, they will pile up.  They will be buffered in your server and streamed
out as bandwidth permits.

> The problem with the scheme you suggested for file transfers, as I
> understand it, is that you send your IP number to the other user.

Yes, but the client<->client HTTP transfer is optional.  I'd like to see
most of the file transfers happen via a server module/daemon.  Either the
sender PUT's the file on the server then notifies the recipient, or a
special streaming pipe could easily be written so that both clients
connect to the server and the data is streamed from one socket to another.

The client<->client file transfer would be most useful in certian
situations where the two clients are closer than the
client->server->client, such as two people on a LAN and the server is on
another part of the net.

> Disregarding privacy issues, this scheme will fail in at least two
> situations.  One is using a firewall and IP forwarding, or if you are
> using a proxy (kinda the same situation really I guess).  Actually come to
> think of it would only fail in the case where you were behind a firewall,
> wouldn't it? 

It depends on the firewall... some detect at the protocol level and would
typically allow HTTP, some do address translation, and some are locked up
tight.

Still, if your client can connect to the server, then the way to get
around any firewall issues would be to just use the server module to
handle the file transfer.

> Anyway, another advantage of implementing file transfers as
> uuencoded messages is that it would be a REALLY easy way to implement it
> in the client.

Only partially true... if the client just wanted to support HTTP/1.1 PUTs,
it just has to open a socket(which it already has to know how to do) print
a few mostly static strings, then dump the file to the socket(or read for
a GET). IMHO it seems far simpler than reassembling messages and
uudecoding them, which in the process added extra size, download time,
and server load.

I really want to avoid in any way possible using or encouraging the
over-use of the main Jabber protocol for anything other than what it was
designed to do, which is communicate micro information(or micromation)
instantly.

I love these discussions though, forces me to rethink my approaches :)

Jer