Forgive my newbieness but I have a couple questions that I'm sure someone here can help me answer.

I'm a bit confused over some of this byte ordering stuff. I'm developing a servent of my own and this is probably the first application I've dealt with in which "big-endian" and "little-endian" byte formats have become an issue.

So, here's where my confusion starts. I've read the "Gnutella Protocol Specification v0.4" doc and early on there are 2 notes (in bold) that read: "Note 1: All fields in the following structures are in little-endian byte order unless otherwise specified." and "Note 2: All IP addresses in the following structures are in IPv4 format. For example, the IPv4 byte array: 0xD0, 0x11, 0x32, 0x04 represents the dotted address 208.17.50.4." OK, I can agree with that... no problem.

I suppose where I start to get confused is later on when the document goes into its description on the various packet formats. Along with the standard description of the IP address field on each packet, in bold it has a note stating "This field is in big-endian format." Does this mean I have to reverse the IP address before sending it out (ie. using the example given, the IP address would be essentially sent as 4.50.17.208)? Or is any conversion required for the IP field at all?

What about other numeric values like "Number of files shared" and "Number of Kilobytes shared" in a Pong packet for example? Do those need to be converted to big-endian as well? The reason I ask is that I downloaded some free code for a particular servent ("coyotella" written in Visual Basic) and in referring to that code, it seems that almost every numeric value is being converted to big-endian format before it's sent, which to me sounds wrong if I am to take "Note 1" (as it appears above) at its word.

Of course, I might be missing something along the way... might Winsock itself require the byte ordering to be reversed? (I think I read something somewhere that said that.) I'm just real confused right at the moment. Maybe I'm just reading too much into things. Then again, maybe I'm just slow. Hopefully one of you Gnutella gurus can help me out.

Any help is GREATLY appreciated.

Oh, and if it makes any difference, I'm developing my servent in Visual Basic 6.0.... ya ya, I know, funny laugh laugh... why don't I develop it in a REAL language? I dunno... "maybe later" is all I can say to that.

Thanks.

-SJF

Anyone?



-SJF

If you could understand this you would be busy with your own client making big bucks, why bother helping another guy who could become your competition?
Why use already written source code that works? Oh yea, you can't use GPL code in a commercial client. Wait! Maybe you can sneak it in so you can make money now! How do you think all the other money making spyware clients got their start?

Soapbox off.

Go look at Gnucleus source code or a linux client to see what is little endian etc it is easier. No where does it tell what a GUID is byte order wise, you have to see what others have done, sorry.
Plus you should be working on features and not wasting your time re-hashing old protocol code that has already been written.
Build on top of what has already been done and then post what you have done so other can build on top of that.

Here are my routines for IP conversion,
Note that I'm using Byte arrays and not Strings:

And this, ladies and gentlemen, is why you should NEVER smoke crack!

Now that my true motives of trying to write a Gnutella client and making millions by riddling it with spyware and adware have been discovered, I think I'll have to retire to a different profession.... like swindling money from old people.

Thanks Mr. Unregistered for your unwarranted conspiracy theory... however, it's just not the answer I'm looking for.

1) I already looked at another couple examples of free VB servent code (yes, I'm using Visual Basic, not C++... if I was using C++, I would be able to refer to Gnucleus or some other servent's code now, wouldn't I?) After reading the code for one servent over more than once and performing some meager testing on my own, I am convinced that it is WRONG aside from being poorly written and incredibly difficult to follow in the first place. The second sample of free servent code I have is utterly unreadable. While I have no doubt it probably works, I have no desire to spend more time deciphering another author's code than actually writing mine.

2) I'd rather not "use existing code" because I don't learn anything that way. If I do it myself, I know what I've done and how I've done it. This also makes it a lot easier when I need to fix things that are wrong or add new features. Besides, as I said in #1, there isn't anything "good" written in VB that I can add onto in the first place.

3) I didn't ask for your opinion on what I really ought to be doing with my coding talents. If I want to write my own code for my own servent, that's my own decision.

4) I didn't ask about GUIDs... dunno where you got that from.


- SJF

Thanks Joetella! You've given me some clues and, after doing a bit more research of my own, I think I may have found the answer I was looking for. Seems to me that the sample code I have is wrong.... which is partly why I was confused in the first place.

Once again, thanks!

- SJF

OK, so maybe *I* was wrong about the sample code being wrong. But hey, those are the breaks.

you can have a look at my Data-Conversion-routines...

see the zip file below

CU

Attached Files

modconversion.zip (1.1 KB, 82 views)

Thanks a bunch Pferdo!

I did download your code, even if it was just to make sure mine was correct (I was able to finish my own data conversion functions recently). I even created a test app and had your function create a value while mine decoded it and vice versa to see if each of our functions came up with the same answers. They do.

Here's my code... just in case you or anyone else wants to see how I did it. It's actually quite different than the way I've seen everyone else do it so far. But, from the meager testing I've done on it, I'm confident it works correctly even though I haven't gotten far enough with my servent yet to be able to use it.

To anyone downloading this code, if you find a bug could you let me know?

Attached Files

moddc.zip (1.5 KB, 93 views)

...while using VB!

A professional C++ and VB programmer "B.Olaf" helped me to make faster routines, and now I finally know a bit more about RTLMoveMemory and the Memory in general... the routines listed below are 2 or even 3 times faster the my old ones: Use them!!!


<code>
Option Explicit
'Functions using 'RtlMoveMemory' by "B.Olaf Rasch" [bolaf-rasch@gmx.de]
Private Declare Sub CopyMemory Lib "kernel32" Alias "RtlMoveMemory" (ByRef lpvDest As Any, ByRef lpvSource As Any, ByVal cbCopy As Long)

Function EncodeNo16(ByVal Number As Long) As String
'"Long" is used to replace "unsigned int"
EncodeNo16 = Space(2)
CopyMemory ByVal EncodeNo16, Number, 2
End Function

Function DecodeNo16(ByVal Number As String) As Long
'"Long" is used to replace "unsigned int"
CopyMemory DecodeNo16, ByVal Number, 2
End Function

Function EncodeNo32(ByVal Number As Double) As String
Dim lngTemp As Long

If Number > 2147483647# Then
lngTemp = CLng(Number - CDbl(4294967296#))
Else
lngTemp = CLng(Number)
End If
EncodeNo32 = Space(4)
CopyMemory ByVal EncodeNo32, lngTemp, 4
End Function

Function DecodeNo32(ByVal Number As String) As Double
Dim lngTemp As Long

CopyMemory lngTemp, ByVal Number, 4
If lngTemp < 0 Then
DecodeNo32 = CDbl(4294967296#) + lngTemp
Else
DecodeNo32 = CDbl(lngTemp)
End If
End Function
</code>

thx!!!