[C++] I don't want it!

[Sorc.Polgara]

The optional packets like 0x25 and 0x59 that you do not have to respond are a pain.

Ok, I want to filter these damn packets so that I can receive what I the packet(s) that I really need.

Lets just say, I send 0x50.  Then BNet sends me the 0x25 packet.  Then I receive the 0x50 response.

In C++ I have to call recv() and it gets the packet that is sent to me.  I am sent to 0x25 which I do not want.  And basically I have to call recv() two freaking times to actually get the 0x50 response, the data that I really need.

Is there a better way than calling recv() two times just to filter out the 0x25 or 0x59 and get the packet response that I need?

[Networks]

why can't you do a simple if statement?
if (packet_id != 0x25 || packet_id != 0x59)
{
  // parsing function here
}

[OnlyMeat]

TCP/IP is a sequential protocol, which means you receive the packets in the same order they were sent. So to access the next data chunk on the network stack, you must first pop the chunk before it.

Thats atleast the way i think of it, although it's not really a stack specifically as stacks work on a LIFO basis. It's more of a queue type FIFO system.

[iago]

TCP/IP is a sequential protocol, which means you receive the packets in the same order they were sent. So to access the next data chunk on the network stack, you must first pop the chunk before it.

Thats atleast the way i think of it, although it's not really a stack specifically as stacks work on a LIFO basis. It's more of a queue type FIFO system.

You have the definition of the TCP/IP stack wrong.  The "stack" is referring to the network layers (physical, data link, address, transport, etc) (yes, I know I call them by the wrong name).  The right term is a "stream".

Anyway, Networks is right, just ignore it if you don't want it.  Calling recv() twice isn't the most horrible thing ever.

You shouldn't actually be depending on the order that stuff is received.  Doing that is a very ba idea.  You should have a single recv() and an event processor.  Don't bother calling any functions if it's not a useful packet.

[Banana fanna fo fanna]

You may be interested in http://en.wikipedia.org/wiki/Finite_state_machine

[iago]

I'm not really sure what you're talking about, but I'll assume it's directed at my last comment.  I don't consider Battle.net to be a finite state machine, except in a few cases.  There are very few packets that have a defined order, though, and it's normally not a good idea to assume that there are any "states".  The real clients don't (as far as I remember) except for "logged in" and "not logged in". 

[UserLoser.]

I'm not really sure what you're talking about, but I'll assume it's directed at my last comment.  I don't consider Battle.net to be a finite state machine, except in a few cases.  There are very few packets that have a defined order, though, and it's normally not a good idea to assume that there are any "states".  The real clients don't (as far as I remember) except for "logged in" and "not logged in". 

IIRC, War3's Game.dll holds different states such as in chat, not in chat, in game, changing pssword, logging on, will flood off, and stuff like that

[iago]

I'm not really sure what you're talking about, but I'll assume it's directed at my last comment.  I don't consider Battle.net to be a finite state machine, except in a few cases.  There are very few packets that have a defined order, though, and it's normally not a good idea to assume that there are any "states".  The real clients don't (as far as I remember) except for "logged in" and "not logged in". 

IIRC, War3's Game.dll holds different states such as in chat, not in chat, in game, changing pssword, logging on, will flood off, and stuff like that

That's still a pretty crappy FSM.

In any case, I don't see how that has anything to do with the original problem.

[MyndFyre]

You may be interested in http://en.wikipedia.org/wiki/Finite_state_machine

Perhaps, but SID_PING and SID_REGISTEREMAIL (that's 0x59 right?) don't actually change the state of the client.  They can change the state of the user's representation on the server, that's all.

The state that IS changed via these packets is whether the machine (client) is processing these packets or receiving more data or whatnot.

[Arta]

Battle.net has several states, although they may not be explicit, and oftentimes there are several ways to move between states. I think an FSM could be useful to someone that likes FSMs.

Examples:

Connected, but no key data
Key data sent, but not logon - the interactions between these states would depend on your pruduct (WAR3: dull, DRTL: interesting)
Logon, but not in chat
In chat
Out of chat, but not in a game
in a game, and out of chat
in a game and in chat (An unreachable state, hopefully!)

Another thing I just realised: certain messages are permitted only in specific states. That could be important to someone who wanted to consider that in their design.

Anyway, all I'm trying to say is, the simplicity of a system doesn't negate the usefulness of modelling it, especially if you don't know about the system and you're trying to get a better understanding of it.

[Adron]

Anyway, all I'm trying to say is, the simplicity of a system doesn't negate the usefulness of modelling it, especially if you don't know about the system and you're trying to get a better understanding of it.

Plus, as soon as you drop multiple threads for a multi-bot program, you're actively developing state machines and tracking the state yourself...

[Hdx]

in a game and in chat (An unreachable state, hopefully!)

Hurm, It is possible.. And has been done...
~-~(HDX)~-~

[Eric]

in a game and in chat (An unreachable state, hopefully!)

Hurm, It is possible.. And has been done...
~-~(HDX)~-~

Once you join or create a game, you are removed from the chatting environment, so no, it hasn't been done.  It's impossible.

[Hdx]

Well If your running through D2GS then no, Login to a realm game, and you can still chat in normal channels. The actual client manually leaves the chat when joining games.
But for D1, your right it is impossible. Hurm, I believe it is possible to be in a game, yet still be chatting with SC to...
~-~(HDX)~-~

[Eric]

Well If your running through D2GS then no, Login to a realm game, and you can still chat in normal channels. The avually client manually leaves the chat when joining games.
But for D1, your right it is impossible. Hurm, I bleave it is possible to be in a game, yet still be chatting with SC to...
~-~(HDX)~-~

You can join a game without informing Battle.net, but if you do that, your Battle.net status will not change.