SIGS/WON

[alice]

Offset   Message Offset  Size   Description
------  --------------  ----   -----------
0x0   -X-  4  Length prefix of following data   (Big Endian)
- - - - - - - - - - - - - - - - - - - - - -
0x4   0x0  4  MessageLength   (Big Endian)
0x8   0x4  4  MessageType   (Big Endian)
0xC   0x8  4  Flags?  (MSB is either 1 or 9)   (Big Endian)
- - - - - - - - - - - - - - - - - - - - - -
0x10   0xC  Variable   Message specific data.  (*Some* data will be Big Endian)
...


Note: The "Flags?" value use is unknown, but values in the most significant byte
other than 1 or 9 cause the message to be discarded. The lower order bytes are
not checked in the comparison. Also, all values passed by the client seem to use
the value 1.

Are you sure the Flags field is Big Endian? Because in all of my packets, its:

Code: [Select]

01 00 00 00

Or maybe the length is wrong... I may end up just discarding that field anyway but I wasn't sure. :unsure:

Like in this example:

Code: [Select]

00 00 00 20 00 00 00 20 00 00 02 68 [01 00 00 00] 4F 75 74 70 6F 73 74 32 5F 55 53 00 33 2E 30 2E 33 2E 30 00 

The part in brackets is the flag field. maybe I'm looking at it wrong  :heh:

(Would've asked you about it on IRC, but you werent on)

[Hooman]

Yes, because the code does endian correction on it. Basically it's a high bit that's set, not a low one. Doesn't seem to be a very important field though as far as I can tell. I think the game might throw away the packet if it's not set to one or two specific values, or if a certain bit or two isn't set, but otherwise it's ignored.

[Highlander]

I don't have internet at home now, so I can't download anything.

When you wanted to play multiplayer, you clicked the correct buttons, and you connected to WON. A client would then check you had the necessary patches installed. You then chose your Login name, and from there you went into the topmost room (New Terra I think it was called, and all games hosted in the room would only be LoS maps)

The different gaming rooms had different gaming possibilities(Los, LR SR etc)

[alice]

Okay, my server is going pretty good so far. I haven't gotten as far as the 2nd connection (not including the login one, but the rooms and the like) but the version checking and everything goes well (for a bit). the Message Formatter is working well (although you have to create the string by using a series of concactenated functions that return the DWORD and other data types right..) This will be done by higher level functions soon, and will eventually lead up to there being working 'rooms'. I already have it set up so that it can accept multiple connections. (I havent bothered to write user authentication code yet, but that doesnt matter right now)  I may have a decently functioning server by the end of the weekend. (although I'm not so sure about game creation/joining but this is a good starting point)

Always nice to have a little side project x]

[Hooman]

Well I've been taking a look at the network code over the last few days. I've got a lot of details filled it on the internal data structures used.

I also found a little about how SIGS can pass the list of player network addresses to the client. On the one hand, this means that SIGS can inform the other clients of a player's external address, but there is one slight problem. The client tries to bind to it's own address. Which means the client must be given a valid internal address on it's own network for the bind to succeed. You can potentially cutom tailor the player's list for each client, so rather than a broadcasted mem copy of a global list, you can update just the client's own address when sending to the client. But there is still a problem. SIGS must know the internal address of the clients. It can very easily get the external address by inspecting the From address when a message or connection arrives at the server, but the internal address would have to be specifically sent inside of a packet. I have yet to observe this behavior for SIGS. This means that even if SIGS can solve the external IP address issue created by home routers, the Outpost 2 network code can still creates another problem with binding to internal addresses.


Also, I've come across many other sections of code that seem to call bind for no real good reason. Suffice it to say fixing up the network code is going to be a pain. The ideal situation is to have a single port for all traffic, which is unbound for clients and initially sends data out, and is bound for a server where traffic must come in. Instead Outpost2 seems to use a seperate port, almost always bound, for pretty much all the different components of the protocol, where the data direction is often intially inbound traffic. If any outgoing traffic is sent first, they seem to have a nasty habit of sending the outgoing data on a different port than they expect the incomming data to come back on.

It seems they've done just about everything they possibly could have to complicate our lives.