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

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.