[JDEV] DSPS

[Richard Dobson]

Why not just get people to use SOCKS5 ?? or similar instead of trying to
reinvent the wheel as it were. If on a corporate LAN and there is a firewall
with no SOCKS server then people probably shouldnt really be trying to
bypass the company firewall anyway. If not then they need to pester the
network manager to set up a SOCKS server to service the jabber clients.

----- Original Message -----
From: "Matthew A. Miller" <linuxwolf at outer-planes.no-ip.com>
To: "JDEV Mailing List" <jdev at jabber.org>; <standards-jig at jabber.org>
Sent: Tuesday, July 23, 2002 7:51 PM
Subject: Re: [JDEV] DSPS


> The original intent of DSPS was to address the problems transferring
> data to/from "firewalled" clients, without introducing new issues (as
> with PASS).
>
> The current spec talks solely about components, although a "stand-alone"
> server could be utilized.  Also, although it is not by design, this
> could handle direct connections, with one of the clients acting as a
> DSPS "server" (for connection-handling only; I know I wouldn't want
> someone trying to tell my client to create a DSPS connection for them
> (-: ).  This (a client-side DSPS "server") is something I've thought
> about just recently, while looking at how we can "clean up" the current
> specification.
>
> At its core, DSPS is fairly easy to support from a client (as others
> have stated).  Also, it's "required" functionality (which, I admit, is
> not clearly differentiated from "optional" functionality) is not all
> that difficult to implement, and (with modifications, or a new spec)
> could be used in direct, P2P connections.
>
> Personally, I think a single "standardized" method of handling "data
> connections" needs to be defined for Jabber, whether it be via DSPS,
> PASS, or even modifications to the current OOB mechanism.  Currently, I
> can see DSPS as becoming an adequate, maybe even preferred, method of
> doing this.
>
> This is my opinion, although your mileage (and opinions) may (most
> likely) vary.
>
>
>
> On Tue, 2002-07-23 at 10:50, Ben Schumacher wrote:
>     (Cross-posting, cause I think it applies to both lists.)
>
>     I agree, that using a stream layer separate from the file transfer
would
>     be preferred, I just think we shouldn't rely on a server as a passthru
in
>     all situations. Working around firewall issues is a problem that has
been
>     solved by nearly every peer-to-peer network in existence, so I assume
>     there has to be a solution that will work for Jabber. In fact, by
keeping
>     the stream layer separate, it should be possible to initiate the
connect
>     from either side and then do a data transfer in either direction. This
way
>     if I am behind a firewall, but the person I'm communicating with
isn't, I
>     can open a connection to them and then push my data across. Perhaps
the
>     DSPS spec should be expanded/altered to the point where it doesn't
>     necessarily imply that a proxy is necessary.
>
>     Currently, the server doesn't have any knowledge of what a user's IP
is
>     beyond socket creation, and I would guess that this will stay this way
in
>     the open source implementation -- it is a privacy concern, after all.
That
>     being said, however, it would be pretty easy to write something that
would
>     have this information (a DSPS component?) available if it was
necessary.
>
>     Does any of this make sense? I'm just trying to avoid
designing/developing
>     something that will not be used, because servers probably won't want
to
>     take the extra bandwidth hit just to provide their users with the
ability
>     to do file transfers.
>
>     bs.
>
>     On Tue, 23 Jul 2002, 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
>
>     _______________________________________________
>     jdev mailing list
>     jdev at jabber.org
> http://mailman.jabber.org/listinfo/jdev
> --
>
> Matt "Linuxwolf" Miller
>
> - Got "JABBER"? (http://www.jabbercentral.org/)
>
> _______________________________________________
> jdev mailing list
> jdev at jabber.org
> http://mailman.jabber.org/listinfo/jdev
>
>