Time to Update BNet Docs

[Blaze]

IIRC, it did have them.

[UserLoser.]

Didn't BnetDocs used to contain a listing of D2GS packets? In any case, BnetDocs does contain some StarCraft UDP packets.

Yes, but I think they were removed because they were documented poorly and a lot of them changed during the last patch.

IIRC, it did have them.

D2GS stuff wasn't ever public, so I don't think you've seen them unless you were a naughty boy.  There were no messages ever related to in-game Starcraft things, from as far back as I can remember. I [have/had] W3GS stuff that I've been waiting to add to BnetDocs, but that's up to Arta when he wants to create a section for them.

[Ringo]

I think the only UDP packets on bnet docs are packets that get sent to the bnserver, but there are still a few UDP packets that get sent to the bnserver that are not listed.

As for SC UDP packets, there is none, and D2GS.. must be held back from public viewing cos there is none on there.

Also there is more to battle.net than a few tcp servers.
It ranges from all the clients protocols that support "battle.net" style play.
(This includes peer on peer UDP even if the bnserver isnt handling them in anyway or recving them)
Alot of the starting UDP packets for SC game room related to the clients BNCS packets and its values in alot of ways. (And i dont mean the UDP version of the TCP 0x09!!)
Fair enough not in ways that would need to be used for writing a simple client, but if u were emulating SC in detail, then yes you would want/need to know this infomation.

This kind of brings fule to my 1st claim, why is D2GS packets held back from PUBLIC viewing? because they dont want the public to have this infomation.
Id have liked to have seen just 1 decompressed packet ID that was documented when i was writeing the protocol a while back, because i was unsure for a while if the decompression was right (it wasnt always a fixed packet ID) but after a while i started to see more clearly how the whole structure worked.

If this infomation wasnt held back, just 1 packet being documented would have saved me alot of time.

I really cant understand why no one wants to document these protocols in detail, i would do it my self but i suck at documentaion and documenting my logs/notes could take ages and it would probly only really make sence to me.

But if somone asks me persionaly about somthing i will answer it if i know the info on it, because i dont get injoyment out of being big headed and thinking im impressing people with the word "programer".
I also feel (like me) many people get injoyment out of writing clients for battle.net protocols, i persionaly do not get injoyment out of holding the resources back for others to injoy them selfs as well.

Its just a shame that some people do. (NO NAMES)

ps: if u take offence to this, then you are one of them people.

and again, not a dig at bnet docs but more of a dig at the generaly attitude of battle.net clients and there game protocols around here...

[Eric]

because they dont want the public to have this infomation.
Id have liked to have seen just 1 decompressed packet ID that was documented when i was writeing the protocol a while back

BlizzHackers had a large list of them.

I really cant understand why no one wants to document these protocols in detail, i would do it my self but i suck at documentaion and documenting my logs/notes could take ages and it would probly only really make sence to me.

... who said it was undocumented?  It's just not publically documented.

[UserLoser.]

because they dont want the public to have this infomation.
Id have liked to have seen just 1 decompressed packet ID that was documented when i was writeing the protocol a while back

BlizzHackers had a large list of them.

I really cant understand why no one wants to document these protocols in detail, i would do it my self but i suck at documentaion and documenting my logs/notes could take ages and it would probly only really make sence to me.

... who said it was undocumented?  It's just not publically documented.

Blizzhackers is also gone

[Ringo]

because they dont want the public to have this infomation.
Id have liked to have seen just 1 decompressed packet ID that was documented when i was writeing the protocol a while back

BlizzHackers had a large list of them.

I really cant understand why no one wants to document these protocols in detail, i would do it my self but i suck at documentaion and documenting my logs/notes could take ages and it would probly only really make sence to me.

... who said it was undocumented?  It's just not publically documented.

If SC UDP protocol is documented but not public, then it wouldnt be known to many as been Documented.

If blizz hackers had a list, then it still doesnt explain why it was held back, and yes i understand the implications of "spam bots" and so on, but this infomation being public really wont change nothing in that sence.

Noob makes d2 realm bot.
Noob obtains D2GS ip from realm packet
Noob sends chat message
Noob has made D2GS spam bot d2 = fucked.

I do beleave that is why u said it is wrong to put this kind of stuff public, because any noob could then do stuff like that.
In regards to D2GS, if any noob tryed to do abuseive stuff, the server would just disconnect them, the server is EXTRAMLY well modorated and almost EVERYTHING has a check sum. (for anti dupe)

So if this info was public and documented in bnet docs fashion, it would saying somthing like:
(DWORD) Object Checksum
witch doesnt help that persion at all when doing somthing abuseive (like making a dupe)

When i kinda started my reply based on SC's UDP, witch as far as i know, is none existant when it comes to any infomation other than what a packet logger can give you.
Again i cant see any reassion why it would be bad to document this protocol.

Anyway..
If somone wrote a "nasty" program and put it up for anyone to download, it isnt much differnt than 1000 people writing there own "nasty" program, the effect is just as great.

[Eric]

When i kinda started my reply based on SC's UDP, witch as far as i know, is none existant when it comes to any infomation other than what a packet logger can give you.

Try using a dissassembler -- you might get a little further.

[Blaze]

IIRC, it did have them.

D2GS stuff wasn't ever public, so I don't think you've seen them unless you were a naughty boy.  There were no messages ever related to in-game Starcraft things, from as far back as I can remember. I [have/had] W3GS stuff that I've been waiting to add to BnetDocs, but that's up to Arta when he wants to create a section for them.

Must be realm I am thinking of.

[Ringo]

I cant comment to much on that, cos i dont know much about assembly, but iv already figgerd out everything about the protocol that is needed to know to write a client for it / and write a playable(ish) game that supports it.
I just lack willingness to continue

[tA-Kane]

As for SC UDP packets, there is none, and D2GS.. must be held back from public viewing cos there is none on there.

I don't recall whether or not D2GS was held back or not when I was able to view it. D2GS packets are no longer on BnetDocs, as far as I can tell however.

The SC UDP packets I was referring to are the same ones you're able to view: PKT_SERVERPING, PKT_KEEPALINE, PKT_CONNTEST, and PKT_CONNTEST2. I'm sure that the other SC packets are similar in structure.

[Ringo]

ye, the few server packets that are missing from the bnet docs are the same.
I will fish them out in a bit

[Eric]

ye, the few server packets that are missing from the bnet docs are the same.
I will fish them out in a bit

0x00: PKT_GAMEDATA
0x03: PKT_CLIENTREQ
0x05: PKT_SERVERPING
0x06: PKT_SELFPING
0x07: PKT_KEEPALIVE
0x08: PKT_CONNTEST
0x09: PKT_CONNTEST2

[MyndFyre]

The following UDP messages are on BnetDocs:
3: [C>0x00]  PKT_GAMEDATA  
3: [C>0x03]  PKT_CLIENTREQ  
1: [S>0x05]  PKT_SERVERPING  
3: [C>0x06]  PKT_SELFPING  
1: [C>0x07]  PKT_KEEPALIVE  
1: [C>0x08]  PKT_CONNTEST  
1: [C>0x09]  PKT_CONNTEST2  

The number 3 next to them indicates that they are draft or placeholders.  The number 1 indicates that they are public.

PKT_GAMEDATA has no information whatsoever, so we can assume it isn't documented.
PKT_CLIENTREQ has information that appears complete, and so it should be reviewed by other staff for correctness.
PKT_SELFPING has no information whatsoever.

[edit] LOL Lord, it's hilarious how we both came up with the same response (more or less).

[Ringo]

ye he listed them,  going by selfping im not sure thats right, i think that packet is a message from the server to tell the client it will no longer be expecting UDP packets form it

the client req?

Where do u think of these names
0x03 has 2 dowrds as i remember, dword 0 means dont answer, dword 1 means answer, generaly with the opersite dword (for game pinging)

You seem to have it rapped up already tho

[edit]
there was more to the 0x06 message that what i said, but i need to check my notes on that, and im pritty sure theres another packet iv seen

[reedit]

The following UDP messages are on BnetDocs:
3: [C>0x00]  PKT_GAMEDATA 
3: [C>0x03]  PKT_CLIENTREQ 
1: [S>0x05]  PKT_SERVERPING 
3: [C>0x06]  PKT_SELFPING 
1: [C>0x07]  PKT_KEEPALIVE 
1: [C>0x08]  PKT_CONNTEST 
1: [C>0x09]  PKT_CONNTEST2 

bnet docs holds back this kinda packets as well? rofl

Battle.net/Starcraft UDP Messages:
[S>0x05]  PKT_SERVERPING 
[C>0x07]  PKT_KEEPALIVE 
[C>0x08]  PKT_CONNTEST 
[C>0x09]  PKT_CONNTEST2 

this is all that is on bnet docs to a normal persion. and as far as i can remember every client below d2 uses them packets
I might have missed somthing, but can you show a client sending this message?
[C>0x06]

[Eric]

going by selfping im not sure thats right

If it's not then battle.snp contains incorrect information.