[JDEV] DSPS

Dave dave at dave.tj
Tue Jul 23 16:30:40 CDT 2002


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




More information about the JDev mailing list