Descriptor Help
 

i am writing a gnutella program in Visual Basic 6 and incoming data looks like this:



?Aó"žÿÚ‰‚t‚ÿx*±8“Õ£‰ntai)

if i have a vb string with a descriptor header in it, how do i translate/read it?

Descriptors in a string
 

You will have to parse the string, discern the Payload length, handle the payload(optional), and pass the descriptor... are you asking how to parse an incoming descriptor?? Or are you befuddled by a descriptor that appears to be a gobbledygook search query? (BearShare sends unintelligible Query descriptors meant for other BearShare clients to check their versions; just decrement their TTL and pass them on...)

Parse the first 23 bytes (you do have the spec, I assume) to determine what kind of descriptor it is.
The descriptor in your example appears to be a Query Descriptor. Beyond that, I can read little from it (it's not in Hex, and I'm too damn lazy to parse it myself).

Which do you need?
The Gnutella Protocol specification
A routine to parse strings??

(As a genuine lazy-***, I use that wonderful feature of C, type casting, to simply reinterpret that string as a DescriptorHeader type :))

LOL
 

I got v0.4 protocal specs.

I figured out the answer to my question this morning. What happens is VB automatically takes the binary info. and converts it to ASCII text. I wanted to know how to convert it back into its original form. I figured it out after lots of thinking and trial and error (took me a while though).

But, I'm still haveing problems. How is text supposed to be encode over the gnutella net? The only thing I get that seems to be ASCII encoded is "GNUTELLA CONNECT/0.4\n\n" and "GNUTELLA OK\n\n". Descriptor IDs appear as that googly junk. And how to i decied what to make the descriptor IDs, and what character set to I encode them with?(their supposed to be text)

Also, the lengths in bytes of the incomming data does not always equal 23 + the payload length. The extra data is almost always less than 23 bytes. What's going on?

Handling the binary data...
 

Very helpful! :D
VB can store the relsults of Winsock.GetData in either a BSTR or an array of integers

A BSTR is a "Basic String", preceeded by it's length (four bytes) which occupies two bytes per character on Unicode supporting systems (VB supports Unicode for purposes of interacting with ActiveX controls), so even though you think there's only one byte per character in the string, that's not the way it's stored in RAM.

Manipulating the data might be easier if you GetData it into an array of integers and interpret it seperately. VB programmers are disadvantaged by the loss of a "typecast" operator, which would allow me to take my array Incoming() As Integer and "reinterpret" its contents as though it were a Type DescriptorHeader... You must parse the elements of the array by hand, but at least it'll be easier than parsing the BSTR (as Gnutella's doesn't use ASCII descriptors like OpenNap).

Also, there's nothing saying you can't retrieve you data into one variable (say a String) and SendData an array of integers! Use whatever's least painful for you :)

It is possible for descriptors to span TCP packets; that is, you may have to GetData again to retrieve the rest of the descriptor...

What lengths are you getting for your payloads?
Pings should always be 0, Pongs always 14, and Pushes always 26... There are NO pads between descriptors in the Gnutella data stream, so you will have to keep careful track of where one descriptor ends and the next begins. If you lose your place, it's curtains; you will be disconnected.

Speaking of the Winsock control...
 

Is your VB software up to date?? (Note that this is NOT causing your problems; it's just something that could cause you problems in the future as you succeed with your servent!)

FIX: Winsock Control Leaks Memory When Unloaded
Last reviewed: February 18, 1998
Article ID: Q171843
The information in this article applies to: Microsoft Visual Basic Professional and Enterprise Editions for Windows, version 5.0

SYMPTOMS
The Winsock control may cause the system to lose memory and system resources, eventually causing the system to stop responding due to running out of memory.

CAUSE
System resources are not properly replenished when a Winsock control is unloaded from memory. If your application often loads and unloads a Winsock control, you may eventually experience this problem.

STATUS
Microsoft has confirmed this to be a bug in the Microsoft products listed at the beginning of this article. We are researching this problem and will post new information here in the Microsoft Knowledge Base as it becomes available. This bug was fixed in Visual Studio 97 Service Pack 3.

Workaround
You can load a fixed number of Winsock controls, or a Winsock control array, on program load and only unload them on program shutdown to work around the memory leak problem. This approach is similar to implementing a Winsock server in SDK using a fixed-sized thread pool and is a more scalable solution than loading a new Winsock control to handle each new client connection. Under the one control per request model, if there are a large number of clients making connections to the server at the same time, the server will soon have too many threads to function at all.
Having a fixed "pool" of Winsock controls can ensure that the server functions properly under a relatively heavy load. A large number of simultaneous client connections will not be able to bring down a server machine. If there are unused controls left in the Winsock control pool when a client connection request comes in, you will assign one control from the pool to handle the client request. After the client request is served, the control is "returned" to the pool. If a client request comes in and all controls in the pool have been assigned out at the moment, you will have to choose to either have the client wait until there are available free controls in the pool, or accept the connection request right away, send a busy message, and then close the socket.
If you are planning a server that could experience really heavy loads, the Winsock control may not be the best tool to use. You should consider overlapped socket I/O with Windows NT I/O Completion Port in a C/C++ SDK program.



Thank you for buying Micro$oft! Don't ya love it!?

:)
 

http://www.ihatemicrosoft.com/
Just don't go there with the Internet Explorer Browser, not cool :)

I got service pack 3 so i guess i'm safe.

Pings and pongs got the right payload lengths, and queries seem to have reasoneable ones. The extra data is probaly parts of descriptors i'm missing. I don't have to worry about losing my spot cause 80% of the time each .getdata command starts at the beginning of a descriptor.

Thanks for the help hydro.

this one's cool too
http://www.pla-netx.com/linebackn/evil/index.html