[JDEV] DSPS

[Julian Missig]

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 
> > > joe at blow.org/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
> > > > jdev at jabber.org
> > > > http://mailman.jabber.org/listinfo/jdev
> > > 
> > > _______________________________________________
> > > jdev mailing list
> > > jdev at jabber.org
> > > http://mailman.jabber.org/listinfo/jdev
> > 
> > 
> > _______________________________________________
> > jdev mailing list
> > jdev at jabber.org
> > http://mailman.jabber.org/listinfo/jdev
> > 
> 
> _______________________________________________
> jdev mailing list
> jdev at jabber.org
> http://mailman.jabber.org/listinfo/jdev