Hmm ... neat. . . - Dave
Julian Missig wrote: > > On Tue, 2002-07-23 at 16:52, Dave wrote: > > invisible to user != invisible to client > > I never said it was invisible to the client. > > > > > Personally, I tend to like the idea of using feature negotiation > > to determine what the client supports. (The client would be > > told by the user (or find out on its own) how/if it can obtain an > > externally-visible listening port, and could use that as a "preferred" > > option for establishing a TCP stream. Else, it can tell the server or > > the other client that it can't obtain an externally-visible listening > > port, and the other client can then decide whether _it_ can obtain an > > externally-visible listening port, or the server can decide whether it's > > willing to provide a PASS or DSPS service, or whatever.) > > Exactly, this is basically what I was proposing. Except that if I did > it, I'd probably have some sort of iq request which would actually get > the receiving client to try connecting to the sending client, and if > that failed, it would fall back on DSPS or PASS or whatever. (The > results would be cached, of course) -- this way when you're on an > internal network, things can still be sent internally without touching > the server, and when you are on different networks, if you can still > access one another's ports, you're not putting extra cruft on the > server's bandwidth. > > I'm sure my proposal could be improved upon. > > Julian > > > > > Julian Missig wrote: > > > > > > It can't possibly be that hard to make a simple method for clients to > > > figure out if they can directly connect using the current file transfer > > > method (http), and if not, use DSPS. It's not that hard to make it > > > invisible to the user. > > > > > > Julian > > > > > > On Tue, 2002-07-23 at 12:10, Justin Karneges wrote: > > > > The problem is that there is otherwise no real clean way to establish a direct > > > > connection. Everyone is behind a firewall these days. > > > > > > > > Maybe jabberd should support a way of getting your external IP address, so > > > > that there could be some sort of stream negotiation between two clients. As > > > > it stands, clients don't even know what their real external address is unless > > > > you were to specify it directly (not exactly user-friendly). > > > > > > > > The "stream" idea IMO makes more sense than just http URLs, because it implies > > > > more possibilities than just file transfer. It also keeps the stream > > > > handshake as a separate layer, which simplifies things when you consider the > > > > various possible methods of transport (TCP, DSPS, PASS, XML-thru-server??), > > > > SSL, reverse-connections, etc. I completely agree with Rob about keeping the > > > > stream layer _separate_ from the file transfer. > > > > > > > > DSPS is dead-easy to use from a client perspective. What we need is something > > > > similar to it, as a standard part of jabberd, that allows clients to ask for > > > > a stream to another JID. Something very simple like: "Oh, you want > > > > [EMAIL PROTECTED]/Home? Connect to this IP address." This might be through DSPS, > > > > or it might be direct, or whatever. I'm just saying, we need a simple way > > > > for clients to ask for a stream. DSPS seems to have a nice interface, but it > > > > assumes we want to route through an external point. Maybe the real solution > > > > is to have an even smarter component that will hook you up directly to the > > > > other person if possible, otherwise fall back to DSPS (all hiding this from > > > > the client). > > > > > > > > The current situation is not optimal. > > > > > > > > -Justin > > > > > > > > On Tuesday 23 July 2002 08:12, Ben Schumacher wrote: > > > > > I, personally, would be against making this the "standard Jabber OOB > > > > > mechanism", or even the "preferred." This puts an unreasonable amount of > > > > > extra load on a server, when it isn't needed. If clients can make direct > > > > > connections to each other, and don't need the benefit of any of the other > > > > > features DSPS provides (read: multicast), then they should transfer files > > > > > directly. > > > > > > > > > > There is no reason to expect that people running servers are going to be > > > > > willing to allow the extra load on their bandwidth. > > > > > > > > > > bs. > > > > > > > > > > _______________________________________________ > > > > > jdev mailing list > > > > > [EMAIL PROTECTED] > > > > > http://mailman.jabber.org/listinfo/jdev > > > > > > > > _______________________________________________ > > > > jdev mailing list > > > > [EMAIL PROTECTED] > > > > http://mailman.jabber.org/listinfo/jdev > > > > > > > > > _______________________________________________ > > > jdev mailing list > > > [EMAIL PROTECTED] > > > http://mailman.jabber.org/listinfo/jdev > > > > > > > _______________________________________________ > > jdev mailing list > > [EMAIL PROTECTED] > > http://mailman.jabber.org/listinfo/jdev > > > _______________________________________________ > jdev mailing list > [EMAIL PROTECTED] > http://mailman.jabber.org/listinfo/jdev > _______________________________________________ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
