Using WCF has both advantages and disadvantages compared to direct socket programming.
The main advantage is that you do not need to care about programming a server loop or communication protocol. You split your communication into function/method calls, include these functions/methods in your contract interface, create a class that implements it, instantiate and open a ServiceHost of that class' type, and your server is ready. For a nice condensed example see http://www.codeproject.com/Articles/14493/WCF-Basic-Client-Server.
There are a few downsides. For one, WCF is not really a small topic, and chances are that you'll still be reading at the time your socket programming would be done. You need to learn how endpoints, addresses, bindings are configured and what combinations make sense.
Furthermore, WCF is a big thing with a lot of abilities and options, and may create overhead when used for very trivial tasks.
I think you indeed should give WCF a try. Your WCF tasks so far are simple. You can modify the example on codeproject to get there quickly; people writing are slow, so overhead is no issue; you will get an understanding of WCF which may help your future.
On the other hand, you already have a socket open, and could just use that for communication. You'd have to read from the socket in a loop, write similar code twice (once for packing, once for unpacking from the stream), always assure that both codes get the same changes, ...