Linux dc++ daemon with detached concurrent console

Asked by Meldo on 2010-03-09

I want to use dc++ on server and be able to have several users to control it remotely. Examining list of existing solutions I've found none suitable.
The particular design i desire is:
1. The DC++ daemon starts and reads command from startup file about what hub(s) it should join and what port it should bind for client
2. The dc++ client connects to control port and display the same thing current GUI displays. There are can be several clients connected to daemon, both can supply search requests change options and so on based on given permission.

Basically, it the brief description of functionality i desire. I did not find a way to implement such scenario with current code base.

I've read you want to separate GUI and back-end layers, so such behavior are is in plans, if it is a true, are there are a curtain person i can communicate to speed up such goal?

Question information

Language:
English Edit question
Status:
Solved
For:
LinuxDC++ Edit question
Assignee:
No assignee Edit question
Solved by:
Razzloss
Solved:
2010-03-09
Last query:
2010-03-09
Last reply:
2010-03-09
Best Razzloss (razzloss) said : #1

1) Only the client part needs to be implemented for this. The current code already autoconnects based on the config in ~/.dc++.

2) ok.

There has been talk about separating the GUI and core even to different processes, but nothing has been done. (There was a client called MultiDC++ made by a retired LinuxDC++ dev, which essentially did this. It was for OSX, but it was never finished and was left to a very alpha state.)

If you want to discuss about implementation there's always IRC linuxdc++@freenode. I'm usually there (though getting a response might take few hours) and if you're lucky you might even see Steven ;). And I guess you can send email to <email address hidden> (don't know if you need to subscribe or anything). Via that list you'll reach me and Steven also.

--RZ

Meldo (earnol) said : #2

Thanks Razzloss, that solved my question.

Steven Sheehy (steven-sheehy) said : #3

It is the lowest priority feature on our list, so unless someone steps up to help it probably won't get done for a long time. Also, I thought you were against the idea Razzloss? Or at least not enthused about it.

Razzloss (razzloss) said : #4

The idea of detachable client/daemon seems cool and I actually liked Phases idea with MultiDC++ (wrote a QT gui for it for linux also). If I've seemed not too thrilled about converting LinuxDC++ to similar setup, it's probably been because of the effort required. With current development going with the pace that it does, implementing this with current dev resources would probably fail or take ages. So if the submitter is willing to work for it I have no objections against this as long as it's done properly (what that means is to be decided).

Submitter actually popped in the IRC channel and left me his email address. I try to find time and write up some ideas on how we should proceed with this. Of course Meldo/earnol can also mail me if he has any thoughts or has already studied some options (my email should be visible in profile page, if it's not it's mynick @gmail.com)

--RZ

Steven Sheehy (steven-sheehy) said : #5

As far as design, I had a few ideas that revolve around MVC. Firstly, the daemon (controller) would need to hold all state (model). Clients (views) would obviously contain a copy of some of the state that they format to display, but they would be considered thing clients. Some of this state is already in the dcpp core, some would have to be kept elsewhere inside the controller. The controller would listen to on() events from the dcpp core, create an event and populate it using the core's datatypes, then send it to the view. Views can also send events to the controller.

The tricky part is the communication between the view and the controller. Should we use some RPC library or write our own? Should the payload be binary or xml based? If it's xml it would be easier to communicate with front-ends that are in a different programming language or on a different operating system, but the tradeoff is of course that it is probably slower. The RPC libraries that I've seen for C/C++ don't seem to be supported very well. If we had something like the excellent twisted library for python or Spring in Java it would be easy. But Alas, nothing is easy in C++.

Meldo (earnol) said : #6

Well, have you had experience with libevent? I had to accept my experience is in mostly win32 development and libevent like all rpc systems i've seen involves codegen step (it can be either python like in event lib or .NET, it does not matter).
So good rpc library should solve all 3 things we need to implement:
1. State sharing
2. Event pushing
3. Remote callback invocation.
I do not see any other things we need, since RPC library will handle all view<->controller communication for us security consideration left aside, BUT it do not care much at the this point at least.