.net...

[MyndFyre]

There is a layer of buffering done directly by the OS for you on any stream socket.  Is this what you meant, or is .NET wasting extra resources by rebuffering beyond that?

Well, they *call* it a buffer, and so I've just more or less gone with the flow....  In reality, I'm supposed to declare a byte[] and the system transfers the received data into the byte[], where I then get to parse it into Unicode or ASCII or UTF-8... or just the dwords, etc.  Buffering is done by the system, I just get the data.

Isn't that what I told you to do in the first place?

Well, I don't know, I guess I misunderstood what you meant....

Also, I find the implementation of your parsing code to be greatly amusing.  It is approximately the same length as my C implementation, except mine does no extra memory allocations, and performs copies only when absolutely necessary (which is generally quite rare due to how I handle incoming messages ).  It's not your fault your parser is so much less efficient, at least not directly.  It's the fault of your choice of language.  Am I correct to assume that, like Java, .NET lacks the concept of pointer arithmetic?  If it has such a concept, your code could potentially be improved quite a bit performance-wise.

Not exactly....  Essentially, the *common type system* doesn't support pointers; however, a language can support pointers.  In my case, using C#, I *could* use pointers, but I'd have to enable "unsafe code support" in the compiler.  The class library doesn't really provide much in the way of pointers, either, so I don't see what the big deal is.  Eh, I'm not overtly concerned about performance right now - it's actually running fairly well.  I might rewrite it to Managed C++ for the next version - but that will be once I *learn* C++.  =)  I just got pointer arithmetic down a couple weeks ago.

I'm having trouble getting WC3 (standard) to authenticate.  Here are my packet orders:

BNLS_AUTHORIZE (0x0e)
BNLS_AUTHORIZEPROOF (0x0f)
SID_AUTH_INFO (0x50)
BNLS_VERIFYSERVER (0x11) -- I'm getting a failure back here, although I might be copying the data wrong.
BNLS_CDKEY (0x01)
SID_AUTH_CHECK (0x51)
BNLS_HASHDATA (0x0b)
SID_LOGINRESPONSE2 (0x3a) -- I don't think I'm getting quite this far.

This works for SC, BW, W2, D2, and (I assume) JStr.  Any ideas?

Thanks!

--Rob

[K]

I might rewrite it to Managed C++ for the next version - but that will be once I *learn* C++.  =)  I just got pointer arithmetic down a couple weeks ago.

Don't bother -- Managed C++ is good if you have some c++ library that you want to quickly port to .NET or need to do things .NET has trouble with.  IMO, if you want managed code, stick with C#; if you want unmanaged, use C/C++.  If you want both, write a dll or write only the required assemblies in managed c++.

[Soul Taker]

...The sender could theoretically call send on one byte at a time...

I've seen that happen with Telnet, makes it very annoying to read packet logs!

[Skywing]

I would check the endianness of the server IP address that send to BNLS.  This should be in network byte order (I don't think anyone stores IP addresses as little endian doublewords).

You cannot use the old-style login method with Warcraft III; the server requires that you use NLS.  You should make the decision on whether or not to use NLS based on the SID_AUTH_INFO reply sent to you by Battle.net.

[TriCk]

I have realised a few things on .NET that are different ...
For instance... u can't get the Winsock's Connection State ... i tried on .NET and gave up due to the amount of things that i just couldnt figure out using winsocks

[Skywing]

I have realised a few things on .NET that are different ...
For instance... u can't get the Winsock's Connection State ... i tried on .NET and gave up due to the amount of things that i just couldnt figure out using winsocks

You are intended to use sockets for serious network programming with .NET.  This means that keeping track of the 'connection state' is up to you.

[MyndFyre]

I have realised a few things on .NET that are different ...
For instance... u can't get the Winsock's Connection State ... i tried on .NET and gave up due to the amount of things that i just couldnt figure out using winsocks

You are intended to use sockets for serious network programming with .NET.  This means that keeping track of the 'connection state' is up to you.

Aye....  Until I started working with Sockets for my bot project, I hardly understood what a byte[] was.  I'm glad, though, that I started this project before I got into my Assembler class...  Now I know about endian-ness and all that good stuff ahead of time.  =D