One library to use is ENet, which implements a generic network API suitable for many games. Or libevent even, which just handles the low-level network events.
There is not a direct need for threads on most platforms, though Windows forces their use for large numbers of clients. Separate threads can be useful when you need a fixed response time or a constant packet send rate, less so for less action-y games.
Send raw bye data, compressed/packed as best you can. It lets clients with worse connections play better, is faster, and keeps your server bandwidth costs down. Some platforms (not yours most likely) have requirements that the game be playable at some low bandwidth like 128kbps, so packing your packets efficiently is a good skill to cultivate. Good game network programmers tend to get hired quickly and paid towards the higher end for game devs, and knowing how to keep bandwidth usage low is part of that skill set. XML is great for a number of reasons, but being small isn't one of them.
Packing mostly comes down to only using as many bits as you need and no more. If all your tiles can be enumerated with 4 bits, pack two tiles per byte. It's a bit more work when things don't line up nicely, but not much. If you use floats, consider writing the code for 16-bit half-precision or custom precision and use that as appropriate (its only a few lines of code - I have a simple template that supports arbitrary mantissa and exponent sizes and optional sign bit that I can also use for half-precision; converting to and from single and double precision is super simple.)
It can be helpful to have a bitstream (vs the usual byte stream) buffer that you can read and write values to.
Actually handling the networking part differs heavily by platform, which is why libevent is useful. Best recommendation there is to not worry deeply about it unless you want to be a pro game network coder. If you so want to learn, your best bet is to just read a lot of books and online docs on hoe each OS's network stack and API works. Making Linux work well is very different than an XBox, for instance.
Only send meaningful changes. If an object is not moving, there is no need to send position. Likewise, if the client he already been sent a chunk if the world and it hadn't changed, don't send it again.
Use some form of Area of Interest filtering to send only relevant things to each client. The client cant see an object 10 miles away, so don't send updates about that object. Just send updates about nearby objects.
As always, read the Gaffer on Games networking articles for a good light introduction to networking games.
