A frame here is one server 'tick' - eg the smallest amount of time to move the action. If we go for 25 fps then a frame is 40ms - eg we update the game each 40 ms. A client gets a snapshot - eg a state of the given area. The client does not need every frame - just enough to draw sensibl smooth animation.
As for the communication - I have an idea here (a bike ride can do wonders to you
We go for completely asnychronous communication.
Basicly - we have network class (for client and server) which spins off a thread that constantly does keepalive (ping or somesuch) with a server / client.
The client will form a request, give it a number and give it to the network class. It sends it to the server.
Server recieves it via its own network class. This class puts the request in the request queue to be processed.
On each frame the server gets one request from each client and creates a 'reply' whitch is sent to the client.
The client network class recieves the reply and puts it in the 'reply' queue. The client will move if there are replies to be processed in the queue.
What is unique is the 'request/reply' ID. It is a number.
Basicly - The client processes reply #1700. Now it formulates what it needs to draw next frame - now numbered #1701. Then it sends it to the server.
The network classes will put recieved requests in the request queue if the request ID is higher then the ID of the last request on the queue, or there is a gap in the requests on the queue that fits the ID (eg requests 1699, 1700 and 1702 are there, but 1701 isn't)
The server creates a reply #1701 sent to the client to process.
Likewise on the client - incoming replies are sent to the reply queue (on the same terms as server requests are) - the client will process all pending replies, and then create requests etc.
This system is foolproff. If the server lags the clients will wait, If the client lags it will just have a queue (up to, say 5 replies) to process.
Also - client may send the request every X ms as long as the X is bigger then the server frame time (40 ms typically)
Also - if we make sure that there are always 2 replies in the reply queue then we can make very efficient animation interpolation - and then we can even send the replies ony 5 times/second and despite 200 ms lag the client will see as smooth animation as his machine allows.