[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