Netfraction Inception

[Pietry]

I've decided to check out Netfraction, the new project that it's supposed to be both a client and a hub for the ADC network.
The project is written in C#, and it runs on Microsoft .NET framework 3.5 and under Mono on *nix systems. Of what I remember, Mono is still 2.0 .NET so Netfraction might run on windows 2.0 .NET also.

I looked over the source code and compiled the projects inside. It seems that the main idea of the project is to make a Netfraction lib that includes basic ADC requirements like base32 or Tiger Hashing, and separate projects for the client and the hub.
The main problem with Netfraction is the current lack of documentation or something user friendly.

I wasn't able to find any readme file, or any license file at all. The compiling process worked ok, but running the client ended up with an exception. The hub started , printing out some log to the console but vanished as trying to type into the box. Finding out on what port the hub is listening is also hard, one has to inspect the source code.

I wasn't able to make further testing, but as a positive thing , the source code looks clean and well written, which is a good point for starting out in making something useful for the people.
ADCPortal wishes good luck to darkKlor with his project and offers the best help it can do : promoting and testing the project.

ADCPortal suggestions:

• Document everything you do, since open source is usually for other people to read and understand
• Don't start making too much at once, try simple things first and don't move too fast, make sure what you did works best
• Always think about the simplest user.

The crew here ( and myself ) hope that Netfraction will soon be something to be proud of and we thank darkKlor for involving and helping the community.

[Toast]

i added it under our links section i do hope more documentation will come and if darkKlor wants a wiki account to document there all he have to do is ask

[darkKlor]

Thanks for the feedback guys

I'll try answer Pietry's post point by point.

1) Mono: It should run on Mono 2.2, but this is .Net 2.0 with some Linq extensions, and I use Linq extensively in the code, so on Windows it's very much a .Net 3.5 affair.

2) The library project NetfractionLib was originally meant to do the hub and client, but that just turned out to be silly, so it's only for the client. The hub does share a lot of source in common though, and especially in the structure of the message handlers.

3) The readme doesn't exist, because I'd forgotten to write one And I should include the licence with the project, but it is at least on the Codeplex page at the top right - it's GPL v2.

4) I don't know why the client crashed, but I haven't looked at that code for about a month, since I started writing the hub.

5) The hub doesn't print much to the console, I've started moving the logging to the system event log, which on Windows you can see via Event Viewer under the Application Logs. You have to run the hub as an Administrator (on Vista at least) the first time you run it so it can create the log 'source'. An installer would normally do this and remove that requirement. Oh and the console the hub shows exits when you press the enter key... I actually have a service/daemon wrapper commented out in the code, because that's how I intend it to be run eventually. The console output was just there in the first place because Console.WriteLine("var a: {0}", a); is a lot easier to type than System.Diagnostics.Debug.WriteLine(String.Format("var a: {0}", a));. But now it's becoming redundant with the event log.

6) The port and IP is in the Hub.xml file, which on my Vista system is at C:\Users\user\AppData\Roaming\DG Solutions\NetfractionHub\.

7) Yeah I really should do some documentation

--------------------------------
At the moment I've just been trying to get the hub to a working state where it can replace Verlihub on our local network, which contains a mix of ApexDC++, BCDC++ and Shakespeer clients (have to move Shakespeer people to jUCy too). I think I have most of ADC/1.0 implemented on the hub side now, so the focus is on extending the reach of the security and logging architecture, and adding general security bot commands. After that I'll look at a Lua plugin via LuaInterface (http://luaforge.net/projects/luainterface/), with a particular focus on enabling Announcer and Trivia bots to meet our local needs.

I hope to get back to the client in amongst all that soon too, but I think that will remain a Windows-only project at least on my part because I like using it to learn WPF programming. The client library is well seperated from the WPF user interface, but the major thing stopping it from compiling on Mono is that I use SQL Server Compact Edition as the database for the hash table and file list. The library can download, but not share files at present, and neither is properly exposed through the client, so it is essentially a chat-only client for now (when it doesn't crash for whatever reason it did in Pietry's case).

I'll try and get some basic documentation done for the Hub over the next week (ignore the client for now I think unless you just want to browse). The Codeplex site enables quite a nice wiki system, though I'll post on here when I've got something worth showing up there.

Thanks again for taking a look, and thanks for the feedback

[Pietry]

Your answer here is a good start for a readme or a basic documentation of what your project does and what it does not.
About the licensing, it's generally a good idea to include a header on each of your source files. Another thing that I noticed is that you may have included versioning system in the repository , which is kind of weird ( repository info with your login perhaps ? ). I'm not too familiar of what MSVC uses for versioning...
Another suggestion : make some automated compile script or job, something like a Makefile or something, or some startup scripts would be nice.


<SecurityBot>
<ClientId>R2UWZEGET5LR3FGLEVPKGYL5ASMW33XZ6AC5YLY</ClientId>
<SessionId>DCBA</SessionId>
<Description>The town sheriff</Description>
</SecurityBot>
<OperatorBot>
<ClientId>O6R5EGD4IU2HRWCBBHU3L2L2O77EMF3JAOJHJOI</ClientId>
<SessionId>ABCD</SessionId>
<Description />
</OperatorBot>

This sounds very DSHub familiar

I don;t quite like the settings path, but that's just my personal opinion. Also the logger seems awkward.

We're glad if testing your project helped, and we will try to continue to watch your project and come up with ideas or finding out bugs.

[Toast]

The bigger the project gets the more the is to document, so documenting from the start and making sure that the source is easy to understand is a good start of getting a large userbase for the application thats why i liked DSHub it was easy to understand and the documentation was excellent.

[darkKlor]

@Pietry:

- I'm not quite sure what you mean about the versioning system? Codeplex uses Team Foundation Server for version-control. A 'change-set' is the same as what Subversion calls a 'revision'. It stores files a lot like Subversion, by only storing the differences between the change-sets, but not entire change-set, but Codeplex gives a convenient one-click download button for each change-set.

- Automated compile script is a good idea, I'll take a look into it.

- Yes the bot names and their SessionId's were inspired by DSHub GenerateNewSessionId in ConnectionManager.cs looks quite a bit like the contents of SID.java in DSHub actually... I just added an acknowledgement comment at the start of the function - it'll appear next time I check-in. Sorry about that

- Sorry I can't agree about the settings path. It's using the Environment.SpecialFolder ApplicationData field which is "The directory that serves as a common repository for application-specific data for the current roaming user." Further, in Mono it is "The directory for application data specific to the user executing the program. On non-Windows operating systems, this path is the value of the environment variable XDG_CONFIG_HOME if it is set, otherwise the ".config" directory in the current user's home directory."

The major reason for doing this is that a Microsoft Design Guideline for Windows Logo certification since Windows 2000, and a practically enforced feature in Vista says DO NOT write to the Program Files directory. It causes quite a headache on our local network whenever a Vista user connects running ApexDC++ (it's a our standard client) because when they try and download something off another peer that peer will see the TTH root flickering like mad in their Connections window, and no downloading will occur. The problem is Apex keeps it's hash database in the Program Files directory, so it cannot be accessed. We have to tell users to go into the Compatability options and select "Run this program as an administrator". Also, with the default download directory being in the Program Files directory, this is redirected to a path that looks like this: C:\Users\user\AppData\Local\VirtualStore\Program Files (x86)\ApexDC++\Downloads. See the Data Redirection heading in this 2006 article: http://technet.microsoft.com/en-au/maga ... 60980.aspx. So, of course the first thing users complain is "I can't find the files I downloaded".

So yeah sorry for the rant, but the pain that applications writing to the Program Files directory has caused makes me a fervent believer against doing so. It's making compatability allowances for programs that ignore these guidelines which helps make Windows slower/more bloated with each version.

Oh and Crise, if you're reading, please fix that (it's the CSIDL_APPDATA path.. http://msdn.microsoft.com/en-us/library ... S.85).aspx)

[Pietry]

Hmm, the SID.java from DSHub is not quite the best way to implement it.. DSHub had some SID problems and I'm not sure if what DSHub does is optimal, eg. it has some performance problems.
You don't need to add some disclaimer, it's just good to see that DSHub had some positive things after all.

About the versioning system, when I opened up the project, MSVC complained about some versioning files that were bad format/missing or something, so I checked: remove all versioning from the project.

[darkKlor]

Yeah the SID generation will take longer the more clients are connected, but I'm not sure of another way to verify the SID is unique.
RFC 4648 says base32 is intended to work on 40-bit groups of input bits, so the 20-bits of random data would be padded with zeros anyway. Not that I know how to generate 20-bits of data in C#, hence I follow your lead and use 24-bits.
You'd need to start using a hashing function if you want uniqueness without checking all the existing SIDs, but even MD5 uses 16 bytes which will make longer SIDs and make the protocol more bandwidth intensive. So I think it just comes down to a trade-off between how bandwidth intensive the protocol is, and how long it takes to connect to a hub with a high number of users.

And yeah the version control issue you experienced is mentioned in the comments here: http://codeplex.codeplex.com/Wiki/View. ... %20clients - it looks like you pressed the correct button. It's just from the way TFS server works. Unfortunately TFS just has better integration into the Visual Studio IDE than any SVN client I've gotten my hands on, but it does create that minor headache for anybody downloading the source. You should be able to use Subversion to keep the source up to date, but I guess whenever the project/solution file is updated you'll have to press ignore/remove once more.

[Toast]

http://adcportal.sourceforge.net/wiki/index.php/Hubsoft
http://adcportal.sourceforge.net/wiki/i ... etfraction

well your on the list now so all we have to do for you is to write an article about your hubsoft since you didn't want a acc

[darkKlor]

I'm starting to build the wiki up... this page in particular should help explain what is going on in the code: http://netfraction.codeplex.com/Wiki/Vi ... chitecture - it is only partially complete though.