It matters because if it's a slow game, ie turnbased, then it's very simple and you can just send the whole state, and the clients doesn't need to compute transitions between states. In an action game, the client will have to interpolate so you get smooth action even though game state data doesn't arrive every frame...
It's a pretty simple scenario. What I do is that on the server I make a unique key from each connected client's remote address (ip & port). This key is put in a player class, that handles all interaction between the server and the player. The player classes are all put in a tree map, and when a packet arrives at the server the key is put together and the correct player is picked from the TreeMap. The incoming packet (in a ByteBuffer) is sent to the player and parsed. Put all keypresses that arrive in a queue or something, then in your game logic loop process each keypress to compute the new state.
Then send the new state to each player... this is a link describing how they update the state in quake 3. Found it interesting and useful, I do something similar. (Send dx from the last state successfully acked).http://www.bookofhook.com/Article/GameDevelopment/TheQuake3NetworkingModel.html
If there are just a small number of entities you'll be ok with sending the whole game state every snapshot (positions, velocity, what they're doing)..
For actions requiring time to perform I'd send the starting time of the action, then the client can compute the following frames based on the starting time. (you don't have time to send what actual animation frame is showing, every frame if you're using a decent frame rate).