Networking

[dandymcgee]

I'm currently the network guy for my software engineering project, and while it's coming along I'm curious as to what approaches others have taken regarding the common networking issues.

For example, say the user logs in via the lobby on the client side of things.

• The user enters a user name and a password.
  The client sends it to the server.
  The server checks it against the database.
  The servers replies to the client.
  The client either grants or denies the user access.

In practice my implementation goes something like (Server Debug Output):

Code: Select all

Received FROM [127.0.0.1]: !AUTH:user,pass;
(depending on whether not it authenticated)
Sent TO [127.0.0.1]: @AUTH:Successful Login!
OR
Sent TO [127.0.0.1]: @AUTH:Invalid username or password.

All incoming data from the server is stored in a giant string on the client side.
In order to check if the log in was successful we're pausing execution (*gasp*) for ~20 ms (local network lag) then searching the string for either "Success" or "Invalid".

One major flaw (of many) with this is the string's contents as a whole persist, so once a log in is successful all future log-ins will be successful regardless.

How do you orchestrate packets so that you know what the exact reply to a specific request is (for instance, a dynamic array of strings is one way that might work for my exact situation)?

We're not lectured at all in class, it's more of a "here's what the end goal, have at it" approach which I like a lot. It just feels like sometimes I'm doing everything in a really horrible way or even just reinventing the wheel (which is usually a valuable experience anyways).

[K-Bal]

Put an ID at the beginning of your message which distinguishs between the different types of messages.

[dandymcgee]

Put an ID at the beginning of your message which distinguishs between the different types of messages.

That's what I'm currently doing... I asked about how to distinguish between different messages of the same type.

[Live-Dimension]

I don't know if this is the 'right' way but i'd probably have some sort of array system that caches each message that comes in, upon which xyz entity can scan and find out any information it needs. Atleast that's the way I'd do it in my head, but there's likely to be a better way.

[EccentricDuck]

Wouldn't it be possible to access and void the contents of the string upon a new login attempt? Not sure if I'm approaching this from the right angle, but that would seem like the simplest way. After all, the user/progam doesn't need to access the previous log on each subsequent login, or if it does you can create a backup in a separate file. That way you're not amassing a single huge log as time goes on, and you'll only have the results of one login attempt each time the user attempts to login.

[K-Bal]

Well, then you are not specific enough. Define an ID for "LoginSuccess" and one for "LoginFail". I don't see why you need to send whole strings for that.

[MrDeathNote]

I agree with k-bal, I use an enum with the options for sending and recieving defined eg playerMoved = 0, playerLogin = 1, playerDiconnected = 2 etc. Then write one byte at the start of the stream your sending with a value from the enum. When the server/client reads the byte they can then identify what the message is by comparing the byte to the enum value so the server/client knows how to process the data.

[dandymcgee]

[thinking out loud]
Alright, thanks for the suggestions guys. It's functional at the moment, but I guess I don't really know how to word what I'm trying to ask since I'm not sure exactly what I'm looking for.

I'll post again later if we encounter any errors. At this point it's probably going to wind up being somewhat of a hack that works.

What I'm getting at is regardless of whether my ID is a string, an int, a char, or whatever I was trying to distinguish between replies.

If I used a dynamic array I would probably search it backward (starting at the most recent addition) looking for the most recent AUTH reply and see whether or not it was successful. That still leaves the problem of lag, if we search too soon (before the new reply is received and added) we could find a denied AUTH request from a previous attempt and deny access for no reason. Maybe we could discard them as they've been accounted for.
[/thinking out loud]

Do you ever feel like you just need to try to explain something to someone else in order to figure out how it's going to work? I think I'm all set now.

[XianForce]

Do you ever feel like you just need to try to explain something to someone else in order to figure out how it's going to work? I think I'm all set now.

I feel that way ALL the time!