I would not keep connection alive it this case. Indifferent of low level TCP socket or other higher level protocol is used, it is a considerable overhead (resources are kept reserved). And it is not a good approach either, when the server is contacting the client.
Although it looks straightforward to build a simple client-server TCP architecture, you gain less than you would think - compared to a framework supported servicing model.
As I understood you are making a thick application, not a web browser based one. And I suppose it is a business application, not a real-time one. Assuming the later, you have to think of your task this way: you have a service provider (your server collecting the data), you have service consumers (the clients sending the data), and there is a transport method. These are different concerns.
WCF is just one approach to deal with this triangle. You ask about efficiency, but in what aspect? Coding, runtime resources, responsiveness, fault tolerance,...? Either way, let the framework work for you.
Consider reading this article: WCF or ASP.NET Web APIs? My two cents on the subject
From what I can see of your task, I would use the new WebAPI to build the service provider (self-hosted or inside IIS) : ASP.NET WebAPI: Getting Started with MVC4 and WebAPI
]. You don't need to create web interface, only expose your method(s), and you can consume them easily even from a WindowsForms application: http://www.developer.com/net/asp/consuming-an-asp.net-web-api-using-httpclient.html
This way you can be sure, that any future upgrade of your application or maintenance will be easier to perform.