Question on Gnucleus socket Close()
 

Hi swabby,

what is the purpose of your extra code in the sockets Close() method? Would it make a difference if I leave it away?
I mean this code snippet:
Mutella (a kind of Unix reincarnation) does something different:
Thx for some helping words, Moak

It seems you try a friendly shutdown, while Max from Mutella loves it the hard way to disconnect.

About friendly disconnect, shouldn't it be:

while(m_bDataSending && !m_bForceDisconnect); //wait until send buffer cleared
AsyncSelect(0);
Shutdown(1); //perform a friendly TCP shutdowm
while(Receive(m_aBuffer, sizeof(m_aBuffer))>0 && !m_bForceDisconnect);
CAsyncSocket::Close()

Greets, Moak

PS: Okay this doesn't work too. Since there is no possibility to get interrupted by a class method that sets m_bForceDisconnect. Perhaps it's a conceptional design weakness in CAsyncSocket?

There are about 10 socket derived classes in gnucleus for a variety of specific purposes. I try to keep the Close() method accross them the same.

You're referencing some old code there though, I'm pretty active with updates usually so I suggest going to gnucleus.net, reading the instructions for getting the latest source and checking it out.

The current code first locks the thread the socket is being closed in and once it is locked does this:

AsyncSelect(0);
ShutDown(1);

I took the clean receive buffer stuff out of there because it was pointless.

There is a huge bug with misdirectedn messages in CAsyncSocket derived classes, but it is fixed by putting AsyncSelect(0); in the deconstructor. It took me sooo long to find that simple fix.

I used guntelladev.com for browsing various Gnutella source code. About your current source, it's on CVS, well perhaps not the best way to attract new coders... but maybe you have enough.

You can browse the very latest source with your web browser at http://cvs.sourceforge.net/cgi-bin/v...us/GnucleusR2/

or at gnucleus.net there are detailed instructions for users with no experience with cvs, to get up and running with wincvs and how to get the latest gnucleus source anonymously.

We always need more developers.

Wow, you did a lot since I looked into your code last time!

Now I wonder that so "less" ppl use your client since the functionality and the source looks nice. Honestly I have to say, I bumped into Gnucleus by accident. I personaly like/use Mutella and so found a way to Gnucleus. Will run/compile Gnucleus when I find more time... haven't done yet. :-)

Just some suggestions: Perhaps you should add this link for browsing code to your home page and a tgz for download too. I know IT IS a minor solution compared to checking out the source, but guess how many coders use CVS today... and will be held back? Speaking about me, I will have a look on the code, when I find more time... at the moment I'm busy with some own stuff and PEERanha. The first step into Mutella/Gnucleus was hard, -on gnutelladev.com- I found no concept design or class descriptions and the code had (like Mutella) very few comments to get a overview. Not ment bad in any way, just thinking loud.

Hope you get more coders, Moak :)

And that is why C++ sucks so bad, you guys won't take the time to document your classes, so how the hell do you expect anyone else but you to use them? Or is that the point? Job security?

Progremmers will never document properly, it's just part of the nature of this type of nural network, so C++ will always suck.

How silly is it to write a commercial app depending on other "classes" that may or may not crash / cause problems beacause you didn't write the code yourself and learn how it works, or the documentation sucks so you call it wrong?

Then the language, what a joke. Some guy decided he wanted his own little language when he came up with this C++ stuff, so he re-wrote the way you speak C. "classes" "destructors" what a joke.

And the :: and string += stuff is way too stupid, now you have these want-to-be Jr. programmers who don't understand how to handle a real string in memory, and how it is all really memory mapped and when you add more like strcat(str1,str2) it takes processor time.

go program basic and leave the real programming to professionals.

Gnucleus is pretty decently commented, anywhere things get complicated there are definently comments to help people out. When ever I write code I think to myself, 'if someone reads this, will they understand it?' If you do have trouble with the source email me, I'll explain it all to you, whatever it is.

Go to http://www.gnucleus.net , on the left hand side there are a set of links to the developer section. I suggest you (Moak) first take a look at the 'Structure' link, this will help you or anyone else understand the basic class structure of gnuclues.

If you open the workspace in MS dev, you will be able to use some of visual studio's advanced source browsing features to get a better feal of the code and how classes are organized.

Hmm.... do you believe from looking on the "structure" picture a new developer will understand what's goin on? For example will he/she understand that CGnuControl is the listening server socket, CnuSock.cpp an accepted client socket which will be turned into CGnuNode or into some other CAsyncSocket derived class after evaluating initiating protocol handshake? Everything without one single line of comment describing what the purpose of each class is, how they work together or what important methods and data structures are supposed to do? Without an overall design guide describing underlying concepts, class purpose, class usage... I feel there might be a lack of documentation. Perhaps ppl need to write a own Gnutella client to understand what's going on. Just thinking loud, perhaps I'm a bad coder...

> If you do have trouble with the source email me, I'll explain it all to you, whatever it is.

thx a lot :)

Gnucleus Structure
 

Your structure picture is not correct IMHO:

- There is no class CGnuDocument, I think you mean CGnucleusDoc.

- The links between 'Doc' and 'View' are wrong. CFrameMain is in the root node, CGnucleusDoc must be linked to CFrameMain not CGnucleus. Also CGnuControl must be linked to CFrameMain not CGnucleusDoc/CGnuDocument.

Hope it helps, Moak

PS: You should rename CGnuControl::CleanDeadSocks to CleanDirtySocks(), kidding, couldn't resist. :)

Open the Gnucleus.cpp file, if you look in the initialize funtion you'll see that there are two lines.

m_pDoc = new CGnucleusDoc(this);
CFrameMain* pMainFrame = new CFrameMain(m_pDoc);

Both CGnucleusDoc and CFrameMain are created and referenced from CGnucleus which is the root node because it is the first class to be run on start up.

The structure represents the fold down on gnucleus, CGnucleus is created, CGnucleus creates CGnucleusDoc and CFrameMain, CGnucleusDoc creates CGnuControl and all the other important data type classes like preferences, chat, sharing, and the cache. When CFrameMain is initialized it creates things like the window, the toolbar, the menu and it also is in charge of creating new windows, we call this the view.

Its called document/view architechture, the data of a program and all the processing to the data is in the document, which is seperate from the view which simply displays the data.

Step throuh the constructors of the program and you can see this, the program is nicely laid out, and the structure picture is a great help in getting from point a in the code to point b.

Thanks for the questions, I like going through the code and verifying things. Thanks too for the typo fix, once I install visio again I'll make sure I change that and update the page. I just put up a screenshots section last night, check it out. :)

Ah, I had an older version of your code again (using CVS now).

Now you create the CGnuControll object in CGnucleusDoc, but the timer function for CGnuControll are still feed via CFrameMain (m_pComm = m_pDoc->m_pComm)...

About nice layout, well, in this particular case you might want encapsulate the timer for the network functions into the network class. For exmaple SetTimer() is a Win32 API functions that allows callback too, then you don't need to send a WM_TIMER via the viewport and the whole way down to a subclass. When using a MFC wrapper, CWnd::SetTimer allows callback too.

Greets, Moak

The Timer in CFrameMain is a global timer, it handles all the sockets, chat, cleaning of old memory, everything. It is centrallized like this so that accurate statistics can be made on the status of gnucleus.

Perhaps you want to show those dependencies also in the 'structure'? I prefer no crossover dependencies, however, it's your code... see it as a suggestion. I just found this when looking into your code about network timers. Then I reported what was irritating in my eyes.

Have a nice weekend, Moak

The stucture represents what creates what, because if you want to access say a download that is going from the transfer window, you would look at the stucture and say, 'ok first i have to get a pointer to the frame, that will give me a pointer to the root, from the root i can get to the document, from the document i can get to the socket controller (cgnucontrol) and from there the download socket list.

There are many many interactions between classes, and thats because its a normal application and class interaction is normal.

Have a nice weekend also, sooo much code to write...

SetTimer() vs timeSetEvent()
 

PS: I did finally decide to avoid SetTimer in my project, since I don't have a viewport/window handle in my later network class (designed to work in a DLL) and also WM_TIMER message has some bottlenecks. If you're interested read http://www.codeproject.com/system/simpletime.asp - especially the last part in the "WM_TIMER" paragraph. I think I will use an own worker thread inside the server network class (or a multimedia timer with timeSetEvent()), this can also handle notifies for finished DNS resolution or friendly TCP disconnects.

Happy coding... Moak

PS: CGnuNod::m_nSecsAlive might be better a DWORD instead of an int, it's the same on standart MS Windows architectures, but you never know your target.

CriticalSection/Mutex
 

Hi again Swabby,
what I wonder... you use a mutex (e.g. CCriticalSection CGnuControl::m_NodeAccess) only on write access to your socket lists (adding/removing nodes), but not also on read access (broadcasting packets). I don't think that std::vector<> is thread safe. I did cross check with Mutella, and Max does use a Mutex on read and write access - which is what i do usually too.

I would expect unexpectable behaviours in Gnucleus - or did I overprotect my code?

Greets, Moak

Not sure, I'll look at it.