Quote:Original post by luzarius
What is the best way for a server to identify a client?

a) When client first logs into the server, the server creates a temporary ID and sends it back to the client. This temporary ID is now both on the server and client. Now when the client sends packets to the server this temporary ID will be in every packet so the server will know where this packet came from.

When the client first logs in, have the client create a random RSA key pair and send the public key only to the server, which stores it in a table with the client's account name. To identify the client in the future:

Client sends account name to server.
Server pick a random number (called a nonce).
Server encrypts this with the clients public key and sends this to the client.
Client must then decrypt this with their private key and reply with the correct number.

This stops spoofing (you can't pretend to be another client just by sending a simple id name, such as their MAC address or id number) and replay attacks (you can't listen in on the communicate and 'replay' the client response next time to spoof).

Quote:Original post by TheTroll
snisarenko, what I am saying is that you really can't get someone's MAC address unless you are on the same Phyisical Network. That information is only used locally by layer 2 traffic.

theTroll

Read my post. I never mentioned obtaining a MAC through a WAN. I implied that you could obtain a MAC by simply runing ipconfig on a friends computer.

Obviously the best way for a profitable game to identify it's clients is by social security number, checking account number, and bank pin number... obviously.

Peachy you forgot the bank card and credit card, please do not forget your pin also.

theTroll

Quote:Original post by luzarius
What is the best way for a server to identify a client?

a) When client first logs into the server, the server creates a temporary ID and sends it back to the client. This temporary ID is now both on the server and client. Now when the client sends packets to the server this temporary ID will be in every packet so the server will know where this packet came from.

OR

b) When client first logs into the server, the server obtains the IP address of the client. Now when the client sends packets to the server, the server will know it is user X of IP address x.x.x.x because the server identifies the user by their IP address.

OR

C) implement both solutions

OR

D) other

Please offer advice! :)

I'd go with D

D)
TCP/IP - This opens a stream. As long as the Stream is open, we know Client X is here. (If login fails, disconnect them or whatever...)
UDP/IP - Connectionles... I'd use the struct sockaddr_in. I've tested 2 clients behind a NAT Router and BOTH had different sockaddr_in's. (Perhaps save the struct sockaddr_in into an array and just do a compare (self written, but a compare) to see if they are the same. (IP and Port may be enough on the compare)

With this, you never should have to send a client or connection ID accross the network.