3rd party integration for satellite users:)

sebi · Post by **sebi** » 2003-12-12 17:42

Hi,

Not sure who to address this, so here it goes:)

A small intro...
We've developed a tool for monitoring the DirecWay FAP level. That's basically a download threshold for satellite users. After they hit it, they get disconnected and have to wait for a while before being able to download again. Anyway, the idea is that this tool lets them stop the downloads before hitting the threshold, so they can continue surfing while the 'bucket' recharges.

So... getting to the point. One of our users suggested we integrate it with DC++, which is not a bad idea. When the application is running, it opens a tcp server that replies to 0 or 1 to client requests, 0 being don't download, and guess what 1 is:), based on the threshold level and user settings. There is only one such app for the whole network.

Integrating with DC++ would mean DC++ checking with the server at some interval to see if it can continue downloading or not.

Our app is at www.fapguard.com. It's also free, though not open source ( more or less a personal hobby right now )... I'm not really looking into changing/compiling the DC++ sources, so I would be greatful if you would be interested in putting such a feature into a future DC++ version. Obviously I'll help as much as I can, such as for example, providing a function that you can call and will return the corresponding 1/0 if you prefer.

Email me at [email protected] if you're interested.

sebi · Post by **sebi** » 2003-12-15 11:31

hmmm.... no reply This means that either there is no interest, or I'm adresing the wrong way. Please direct me if 2nd:)

Qbert · Post by **Qbert** » 2003-12-15 12:25

sebi wrote:That's basically a download threshold for satellite users. After they hit it, they get disconnected and have to wait for a while before being able to downlad again.

I would see much better use of this feature in an external application, since any network application would affect and be effected by it. And so integrating with DC++, while being beneficial, I think would be more beneficial if kept as an external program.
(For example, if integrated into DC++, an external program for the same function would still probably be needed since you may use other applications which access the net.)

Post by **GargoyleMT** » 2003-12-17 16:46

sebi wrote:Our app is at www.fapguard.com. It's also free, though not open source ( more or less a personal hobby right now )... I'm not really looking into changing/compiling the DC++ sources, so I would be greatful if you would be interested in putting such a feature into a future DC++ version.

Is it license compatible with the GPL? If not, it cannot be linked into DC++.

You might work on making an API (Winamp would be a simple model) for your application and then coding an addition (that can be GPLed) to DC++ for it. If you want pointers, I'll be happy to help you out, the up/download code is something I'm familar with.

- Todd

sebi · Post by **sebi** » 2003-12-17 17:32

cool. No it's not GPL. API... it's basically there, as we have the server that accepts connections and says download or not download. I can write an API, or rather 1 function, that would connect to the server and return 0 or 1. That would not be a problem.

About integrating that into DC++.... not sure how DC++ can be extended... I could code it into DC++, but then we'd have to recompile each new release of DC++, which wouldn't be funny:) Any hints would be appreciated.

sebi · Post by **sebi** » 2003-12-17 17:38

oh, and

I would see much better use of this feature in an external application, since any network application would affect and be effected by it. And so integrating with DC++, while being beneficial, I think would be more beneficial if kept as an external program.

Edit: Added a quote here, looks much better than ""
//joakim_tosteberg

Very true, but right now I'm not really looking into writting a firewall, that is if someone doesn't have an intermediate driver written and willing to share it:)

Plus, the solution I'm talking about looks at the problem the other way arround ( prolly the wrong way that is:) ) While making our app a firewall would make it work with any internet application, on the other hand adding this to DC++ would make DC++ work with any application similar to ours.... a server is easier to write than a firewall....

Don't take it the wrong way. I'm not saying that all the download apps should bend to our model. I'm just talking about an easier solution:)

sebi · Post by **sebi** » 2003-12-22 15:40

so..... any chance of starting this? I'd do the extension, if it can get integrated in the future releases... and get a few hints as to an easy way to pause/resume dc++ downloads. I know my way with c++, but am not the best at understanding other people's code:)

Probaly do a more general extension, like dc++ loading and calling a dll which tells it if to download or not, so it can be used for other things as well.

Would use a default dll that just returns true ( download ), which can be replaced by other extensions as needed.

What do you think?

Post by **GargoyleMT** » 2003-12-22 17:21

sebi wrote:so..... any chance of starting this? I'd do the extension, if it can get integrated in the future releases... and get a few hints as to an easy way to pause/resume dc++ downloads. I know my way with c++, but am not the best at understanding other people's code:)

Well, two places where DC++ might need to be patched would seem to be the QueueManager (which starts downloads), and the BufferedSocket, where actual reading from the socket takes place.

Probaly do a more general extension, like dc++ loading and calling a dll which tells it if to download or not, so it can be used for other things as well.

Again, is the product GPL compatible? You cannot have a GPL application rely on a closed source DLL (dynamic linking at runtime is still creating a derived work, which must be GPL compatible).

Would use a default dll that just returns true ( download ), which can be replaced by other extensions as needed.

Sure.

The Winamp API is as simple as getting a window handle and SendMessage'ing a specific message to it.

sebi · Post by **sebi** » 2003-12-23 12:30

Well, two places where DC++ might need to be patched would seem to be the QueueManager (which starts downloads), and the BufferedSocket, where actual reading from the socket takes place.

or maybe just limit the dl speed?

Again, is the product GPL compatible? You cannot have a GPL application rely on a closed source DLL (dynamic linking at runtime is still creating a derived work, which must be GPL compatible).

I have no problem with making the dll opensource... not sure what GPL implies, but there's no problem with that.

The Winamp API is as simple as getting a window handle and SendMessage'ing a specific message to it.

Maybe that's simpler, but I wonder how they get the window handle... will have to check it out.[/quote]

Post by **GargoyleMT** » 2003-12-23 13:33

sebi wrote:or maybe just limit the dl speed?

Well, my code for download speed limiting is in BufferedSocket and DownloadManager... It reads a per-second limit from the SettingsManager class, but if you have a "limit to this many bytes in this time period" representation, that would also be workable.

Again, is the product GPL compatible? You cannot have a GPL application rely on a closed source DLL (dynamic linking at runtime is still creating a derived work, which must be GPL compatible).

I have no problem with making the dll opensource... not sure what GPL implies, but there's no problem with that.

You should read the GPL aand decide if it's for you.
License: http://www.fsf.org/licenses/gpl.html
Here's the FAQ: http://www.fsf.org/licenses/gpl-faq.html

In particular, if you GPL your DLL, you can't have it linked in with non-GPL code - i.e. the rest of your application. I know licensing can be a bother, but you need to know whether or not it'll be a show stopper...

Maybe that's simpler, but I wonder how they get the window handle... will have to check it out.

Here's the beginning of my /winamp code from my mod:

Code: Select all

HWND hwndWinamp = FindWindow("Winamp v1.x", NULL);
      if (hwndWinamp) {

(they use a constant window class name)

joakim_tosteberg · Post by **joakim_tosteberg** » 2003-12-23 14:29

GargoyleMT wrote:In particular, if you GPL your DLL, you can't have it linked in with non-GPL code - i.e. the rest of your application. I know licensing can be a bother, but you need to know whether or not it'll be a show stopper...

Wouldn't the LGPL solve this problem? Or does it become "uncompatible" with dc++:s GPL then? ( If it would do the work at all, haven't really studied the licences very much :wink:

)

Post by **GargoyleMT** » 2003-12-23 17:15

joakim_tosteberg wrote:Wouldn't the LGPL solve this problem? Or does it become "uncompatible" with dc++:s GPL then? ( If it would do the work at all, haven't really studied the licences very much )

You know, I'm not sure either. A look over the FAQ doesn't turn up much, reading through the Lesser GPL license itself comes next...

sebi · Post by **sebi** » 2003-12-24 09:11

hmmm... FindWindow... pretty cool. Will have to look some more into it. Didn't work much directly with winapi, as I do most my programming in c++ builder, which has all this done for you. Starting to think I should learn a bit more winapi:)

GPL. The dll would be linked to dc++. So dc++ GPL, links with the dll which is also GPL. What would the problem be? Of course the dll would use our app which is not GPL, but that's like internet explorer using apache. Anyway, will read the GPL description these days.

The only question that remains, is if you would include our mod/patch in your releases. Because otherwise, we'd have to recompile DC++ for every release, and I'm not really looking forward to that.

Thanks for your help so far:)

Post by **GargoyleMT** » 2003-12-24 17:57

sebi wrote:GPL. The dll would be linked to dc++. So dc++ GPL, links with the dll which is also GPL. What would the problem be? Of course the dll would use our app which is not GPL, but that's like internet explorer using apache.

It's the last bit that will cause trouble, if the DLL is linked in with your app.

The only question that remains, is if you would include our mod/patch in your releases. Because otherwise, we'd have to recompile DC++ for every release, and I'm not really looking forward to that.

Well, I'm not arne, but I think if you present him with a patch, and it doesn't affect non-satellite users adversely and doesn't require much/any upkeep, it stands a good chance of inclusion.

Recompiling DC++ isn't a big deal anyway, you can choose to have Sourceforge notify you of new DC++ releases, and if your patch touches just a few files, keep a unified diff of the changes, and use patch to fix things up. There could be a conflict or two to fix up, but you're in a much easier position than most DC++ mods....

Or better yet, recruit a programming saavy user to do it for you.

(that's if DC++ doesn't include your patch)

sebi · Post by **sebi** » 2003-12-26 15:43

Ok, thanks, will have a go at it after I get back from the holidays:) The dll would link to our non GPL app, but it will do so over TCP/IP client server stuff, hence the comparation between apache and internet explorer.

DC++

3rd party integration for satellite users:)

3rd party integration for satellite users:)

Re: 3rd party integration for satellite users:)

Who is online