Remote control protocol

Discussion and questions about clients
Locked
OCTAGRAM
Junior Member
Posts: 10
Joined: 31 Jul 2011, 07:25
Location: Barnaul, Russia
Contact:

Remote control protocol

Post by OCTAGRAM » 31 Jul 2011, 11:14

DC++ in it's current state reminds me good ol' DOS machines with Arachne web browser and a dial-up modem. Arachne opens a connection on a COM port, dials ISP and uses Internet connection exclusivelly. DC++ is similar to Arachne in the sense it utilizes p2p connection exclusivelly as well. Other program can also connect to the same hubs, but it's often senseless. There should be just 1 connection with every hub, and client software should be able to share it. E. g. it should be possible to write a Pidgin plugin and chat with users in Pidgin or it should be possible to write a FAR Manager plugin and browse fileshares from FAR Manager. I2P and FreeNet provide TCP port for receiving application requests.

It would be nice if other software could be able to self-update through an established DC++ connection.

Implementing HTTP server enables several yet another attractive opportunities for browser/DC++ interoperation. For your interest, I know 6 ways of interaction between website and a client application:
1. Downloading and launching a file with associated extension
2. Non-standard URI scheme
3. Browser plugin
4. A website opens not in a regular browser, but inside an application, and application provides additional APIs inside an embedded browser
5. Semiproxy (Facebook, Mail.ru, Yandex). Both browser and application login into a common platform (usually a huge platform), and both sides communicate through this platform. I saw this in Mail.ru agent.
6. AJAX@localhost. Attractive, but not widely explored. Examples are BitTorrent DNA, Magnet, probably Spoon.

DC++ is currently stuck at the first 2. magnet:, dchub:, adc:, nmdcs:, adcs: URIs and .dcls metafiles. But this is very limited way to communicate. There is a huge abyss between browser and DC++. Non-standard URIs and .dcls metafiles are artillery bullets that are being manually launched in one direction and http: links also being opened manually from DC++ client. It's not possible to manually open a channel for instant messaging between browser page and DC++ client.
3 and 4 are hard to implement.
5 is usually about dependence on 1 of a big players. However, it is possible(5b) currently to write a Lua plugin that will connect to arbitrary web services and execute allowed set of commands.
6 is most attractive for me. It is better compared to 5b because it is easier to automate and it is easier (for webmasters) to implement. Making AJAX request right to DC++ is simpler than storing a request to a platform, delivering request to DC++ via platform and delivering the response back to the browser page via AJAX.

Internet is cool because there is an interoperation between sites. There is OpenID, OAuth, PAvatar and so on. Desktop applications usually stand apart from web sites. AJAX@localhost is a missing piece of puzzle.

So I believe HTTP server is a must, but not the only mean of communication.

There are several wishes regards both uses:

app<->dc++:

There are no strict boundaries between different applications running from a single user, so protecting from malicious applications is not possible. However, it's better to be protected from other applications launched from another user, so we can use X11-style cookies. (or checking origin using e. g. named pipe instead of TCP port).

It should be possible to bind the RPC port to the outer IPs, with user/login authorization for application.

browser<->dc++:

Magnet draft has already defined several protocol-agnostic aspects of p2p client discovery.

My wishes are: DC++ client should aid different schemes of interoperation. Maybe even URL #fragments. HTML5 WebSockets, OPTIONS and Flash cross-domain.xml will also be helpful.

It should operate in the case when one is using domain "localhost.toom.su" (yep, I add "localhost" subdomain in every domain controlled by me; it's a pity I have nothing to use it on) and making direct xml http requests. It should operate in the case when one is using "localhost" and inserting <SCRIPT>s. It should probably implement OAuth (if applicable) or something similar. Allowed and denied domains should also be viewed and managed through the main client interface.

It should be possible to query for a presence of a file with specified TTH in the share and/or download queue.

There should be several non-AJAX handlers:

Depending on a presence of a specified presence of a file with specified TTH should return an image of specified size. This image should have different colours for downloaded, abscent, download in progress, pause and other client-specific states. This image should be served without authorization, so it's not the same as JavaScript query for file presence.
Indicator images for hub online status and user online status.

File download handlers similar to the ones found in BitTorrent DNA. It looks like BitTorrent DNA can serve Byte-Range requests to Flash player.

The thread is about making specification and thinking about possible use cases.

Locked