Typically the server has a some sort of connection identification, whether or not it is implemented at the network layer or in the library you are using, or whether you have to implement it yourself is not something I can answer, as I am not familiar with the technology you mentioned you are using for the client, and it can vary a lot.
Essentially in its barest form the client is sending some sort of connection identifier in each packet to the server. Same principle applies to coordinates. Just like there is an identifier for who is connecting (which should be two part -- when the client is initially connecting it should pass some sort of key to the server to say "hey this is me, please give me access", and the server will generate another key to use in tandem with the key the client provided for subsequent requests to prove to both the client and server that "hey, this packet was sent by someone claiming to be X client, and X client should know about Y piece of information, which they do, so they must really be X client"), there is also an identifier for what kind of information is being sent to the server -- unlike the connection identifier however which is dynamic and only known at runtime, this is static, and is known to all clients and servers beforehand.
Before you jump the gun and implement connection identifiers however, check to see if you get multiple sockets or connections from your server networking library. If you only get a single one that spits out packets, you will need to write your own connection identification code -- which means all of your packets will have a client identifier generated by the client, a shared secret between the client and server that the server generated on the connection request, the packet type/identifier, and finally the packet data, but if the server library provides connection and socket information for each socket/connection, this is likely already being taken care of, and all you need are the packet identifier/type and packet data.