Thanks a ton Waqas. This is probably what I was looking for.
Just some minor queries :: a) Once the proxies are setup (i.e. there is a link (Alice's WebDAV hosted in "httpd") <==> (Tom's server) <==> (Bob's browser), then the user-experience will be the same as though Alice and Bob are on the same network, right? b) What is your general opinion on this approach? Would the amount and complexity of the added code (proxy-setup) be worthwhile, than looking for a possible alternative like "upload-files-to-central-server-and-then-download-from-there"? Anyways, thanks a ton for the confidence :) Thanks and Regards, Ajay On Wed, Mar 28, 2012 at 2:00 PM, Waqas Hussain <waqa...@gmail.com> wrote: > On Wed, Mar 28, 2012 at 9:33 AM, Ajay Garg <ajaygargn...@gmail.com> wrote: > > Hi all. > > > > I have already posted the following query at "JAdmin" mailing list; but > I am > > not sure as to which mailing list is the appropriate one. > > > > Anyhow, since my query refers to a very conceptual doubt, I am posting > this > > here as well, to avoid any delay. I am sorry if I sound too desperate, > but > > the answer to the following query is indispensable; only then can I > decide > > on the go/no-go for the design. > > > > > > > ####################################################################################################### > > There are two users Bob and Alice. Each of Bob and Alice have setup a > WebDAV > > server on their local machines over SSL, and listen on port 443. In a > normal > > environment, Bob is able to access Alice's share by typing "https:// > <Alice's > > IP Address>/webdav". Alice is able to the same. > > > > Next, both Alice and Bob log onto a Jabber server set up by their common > > friend Tom; and the only way they can communicate is via Jabber. They > still > > want to make their shares available to each other; and wish for the > simplest > > way to do it - via their browser. So, can Tom configure his Jabber > server in > > a manner, so as to allow Bob and Alice to access each other's WebDAV > shares' > > via their respective browsers? > > > ####################################################################################################### > > > > > > Looking forward to a reply. > > > > > > Thanks and Regards, > > Ajay > > So your problem basically boils down to a reverse HTTP(S) proxy, > tunneling over XMPP. You are probably considering XMPP to avoid > worrying about IP addresses and firewalls, and trying to expose local > services to contacts. > > Possible? Sure. But note, at a minimum you'll need a custom client, > and a custom server (or server plugin), since nothing supports your > use-case out of the box. > > Here's how I might do this: > > I'm assuming Tom's server is public (not behind a firewall, can accept > connections). I'm assuming Alice's server is behind a NAT/firewall, so > can't accept direct connections. I'm also assuming you want large file > transfer support. > > Alice is running a local httpd. Alice's client will open a TCP stream > to Tom's server, and a TCP stream to the local httpd, and then will > act as a dumb proxy between these connections. This is fairly simple. > You can probably use some existing HTTP proxy codebase. The client > initiates the connections when it receives a signal over XMPP from the > server. There can be multiple connections at the same time. > > On the server end, it's a bit more complicated. Take an existing HTTP > proxy codebase. Then you need to modify its connection opening logic > to signal the appropriate client via the XMPP server, which opens a > reverse connection to the server proxy. Then that connection can be > used for proxying as normal. > > Here's how it would flow: > > 1. Bob requests http://tom.com/webdav/alice/ using his web browser > 2. Tom's server signals Alice's client > 3. Alice's client connects to Tom's server and local server > 4. Tom's server forwards request to Alice's server via Alice's client > 5. Bob gets response from Alice's server via the two proxies > > Why use XMPP for this? For signalling, authentication, persistent > connections, and other various features XMPP has standardized. > > Why not transfer data over XMPP itself? That would be much simpler, > but large file transfers would be highly inefficient, so we open > separate connections for the HTTP tunneling. > > -- > Waqas Hussain > _______________________________________________ > JDev mailing list > Info: http://mail.jabber.org/mailman/listinfo/jdev > Unsubscribe: jdev-unsubscr...@jabber.org > _______________________________________________ >
_______________________________________________ JDev mailing list Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org _______________________________________________
