APIManager / APIClient

To make things even easier to maintain, I decided to rename the RemoteAPI class to APIClient (and make it a component) and add a APIManager component that will automatically poll for events and trigger events when needed!

It’ll have the option to trigger on the ui thread (default) or on the worker thread :)

Multi-search support!

Here some screens of the progress on multi-search support (cannot download yet though)

This also uses the event system! :)

Ack! No port then I guess :(

Looks like the port can change during requests. Ack, ack, triple ack!

Fixed atm by just removing the port part in the check :/

Lucky we got the cookie now ^^

Event System

I started bare work on an event system. Currently you always had to retrieve ALL downloads / nodes / searches (in the old version that is)

Now a client can subscribe for events, as simple as this:

RemoteAPI.RegisterEvents(RemoteAPI.EventType.NodeChange);

Then you can poll for events using for example this

var nodeEvents = RemoteAPI.GetNodeEvents();

This will clean any events that were stored as well.

This event-cache is per-client so multiple client can subscribe, and by getting the events, they will only clear their own basket.

Update 4:26

I finished the first part of my events : it now works for all outgoing node connections.

Here some NEW screenshots from the new client using the new efficient event system instead of retrieving all connections each time!

 Connections! Wooh!

 

 

 

 

 

 

 

 

 

 After clicking Outgoing (so it is unchecked)

After clicking Outgoing (so it is checked again)

As you can see, the times didn’t update, I noticed and fixed it :)

Troubles (Solved!)

As I feared, the GnucCOM object is dying within the service :/

Looking for a solution for this!

Found my solution @ http://www.albahari.com/threading/part3.aspx

Thread t = new Thread (...); t.SetApartmentState (ApartmentState.STA);

Also, I’m using Application.DoEvents() know but I admit that I’m not sure if this even helps in any way since this is a service and not a Windows Forms application.

Reason why I think I need this was because I use GnucCOM, and COM is not compatible with the default .NET threading apartment state.

Anyhow, let the coding proceed!

Most simple console application

using System; using System.Linq; using APILib; namespace ServiceTest {     class Program     {         static void Main(string[] args)         {             var api = new RemoteAPI();             api.Open("http://localhost:6351/");             api.Create();             api.Cache.AddWebCache("http://grantgalitz.com/Beacon/gwc.php");             api.Core.Connect();             while(true)             {                 var res = api.Net.GetNodes();                  Console.WriteLine(“Nodes connected / connecting” + res.Count());                 Console.ReadLine();             }         }     } }

SharpWired : Windows Service

Since the tech I use usually requires admin I decided to let it run as a windows service.

This service will have the following features:

• Multiple ‘clients’ can connect through it (each having its own GnucCOM instance)
• Multiple clients can connect to the same GnucCOM instance (if the client that initially created the object allowed it)
• Extend previous with support for remote connections to the GnucCOM instance
• Protection against abuse by verifying the following properties:
• Session id
• client id
• Password (for attach)
• Client ip:port check (+optional cookie check)
• Allow Remote (or not)

All this code will be GPL but I ask that IF you use the windows service, and modify it, that you let it listen on another address (port)!

One not, since we use ip:port check for protection, this means that (in case you would want more) you need to create a new webclient instance PER ‘local client’! Looking into this some more…

Considering adding ‘cookies’ above the ip:port check to further refine the ability to detect who is who.

Added! Makes it more difficult though to call methods BUT I will make a Web API wrapper for that (might release the code, we’ll see)

Example:

using (ToolsAPI.CookieContext(core.InnerChannel, myCookie)) {     Console.WriteLine(core.GetClientAddress()); }

Disadvantage : Only works using HTTP-based WCF services.

SharpWire³

I’ve decided I wasn’t so happy with the current API-design to communicate with GnucCOM.

 

Therefore I decided to start SharpWire anew. The GUI will be kept mostly, but the core, the innerworking, will change alot.

Also, to comply with the GPL-license, I seperated my private code from the GPL code. I’ll give the location of the public svn trunk once the API is stable-ish :)

And there was.. a download!

Pix or it didn’t happen

 

I shut down the app before the song could be downloaded, just so you know ;)

SharpWire : Before, now and then

Old version

New version

Goal is to make a decent Windows 7 only (might work on Vista) Gnutella(2?) client

It uses the latest available version of GnucCOM. This is released under GPL but since I cannot release the code under GPL (I’m using MS-PL code parts…) I had to figure out a solution.

Solution is a GPL ‘loophole’ (ucky :p) by running GnucCOM in a seperate service application, and communicate as if it was a webservice.

The ‘service’ code IS GPL including my ‘wrapper’ for GnucCOM to make things easier :)

Communication is done using WCF but any webservice client (SOAP?) should be able to connect :)

Enjoy the screens!