[JDEV] DSPS

Dave dave at dave.tj
Tue Jul 23 15:52:41 CDT 2002


invisible to user != invisible to 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.)

 - Dave


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
> 




More information about the JDev mailing list