I would highly recommend first considering the major points of network play in general regarding any client->server->client model.
1) What data will you be transferring to/from users? to/from servers?
2) Will you go direct (configuration per user is high/speed may be good/use for more than a 2 player is questionable)?
3) Will you use Push Connections from cloud? Maybe look up that term if you don't get it. It can help you avoid the headaches of Firewalls.
4) How often will you be transfering state between users? This impacts performance which impacts latency and gameplay.
5) Do you want people to host? Will you make a match maker service in the cloud? Or local on the network? Or Both?
6) How will you implement session management (unique per session)? (You can't just disconnect someone from desynchronizing - if you require perfect sessions, but end up using UDP, you may find yourself with constant "why can't I keep the computers connected to each other" problems.
7) How will you implement message management (order of packets in case you utilize UDP)? How will you dispatch the messages to your system? You MUST utilize some async method, if your game "pauses" waiting for network packets, well we've all seen what that looks like in a game... It makes it really choppy. Consider a delay between processing and receipt. Look at Quake UDP network design Con/Pro for understanding how you can utilize delay to improve usability. (
http://fabiensanglard.net/quake3/network.php) This is worth a read, understand what's going on and why.
8) How will you authenticate users into the cloud for any cloud bits? Local authentication may not be necessary for LAN, but absolutely an issue for WAN.
9) For supremely fast updates, consider UDP - there are many blogs on UDP vs. TCP, I highly recommend using both for different purposes, and at the same time.
10) Are you trying for a given platform? Windows, mobile, etc., look at networking aspects from that platform specifically. Look at HTTP from client to cloud - and if you have connection pooling and use keep-alive, can probably manage this effectively using HTTP, efficiently and for a high latency game (chess, it's prob ok) but maybe too slow, too much overhead for yours.
Do not confuse "how you do networking" with game design in regards to networking. Your need for features will help you pick the method. You could use hundreds of different protocols, start with the component design, frequency of updates, then look at which protocols will meet your needs. Finally, don't be in a rush. Proper consistent network functionality will make the rest of the game shine, but without it, a great game becomes unplayable.
If you want to get into the guts, get TCP Illustrated latest revision and master networking including DNS, IPV4/6, TCP, and UDP.