Waqas, to add to your point of not using XMPP itself to transfer files; using (tunnelled) HTTP would prevent re-inventing the wheel of the file-listing and download-capability that comes in with WebDAV-in-a-browser-client.
Thanks again. I am looking for implementation mechanics, on lines of the design suggested by you. :-) Thanks and Regards Ajay On Wed, Mar 28, 2012 at 2:16 PM, Ajay Garg <[email protected]> wrote: > 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 <[email protected]> wrote: > >> On Wed, Mar 28, 2012 at 9:33 AM, Ajay Garg <[email protected]> >> 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: [email protected] >> _______________________________________________ >> > >
_______________________________________________ JDev mailing list Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: [email protected] _______________________________________________
