I'm building a small application composed of:

  • Client (command-line)

  • Business logic (remote server)

It's a simple game of tick-tack-toe where the client sends information to the server about which field has been marked and the server returns an updated ASCII drawing of the board.

My initial idea was to implement the client-server communication using RPC over HTTP.

However, since HTTP uses a TCP connection anyway, and I don't seem to have a need for the HTTP headers (I'm sending really small amounts of data) wouldn't it be a better idea to just use a plain TCP connection and do RPC that way?

Could I run into any problems if a large amount of concurrent players (clients) decided to connect to my game (i.e. should I close the TCP connection with every request or keep it open while the game goes on)?

  • 3
    You've actually got several questions in one here. You certainly can use a raw TCP socket if you want, though depending on where your players are you might run into firewall problems. I think that's why most modern games that need server-side pushes and similar use Web Sockets instead.
    – Paul
    Commented Sep 29, 2017 at 20:48
  • 3
    Using HTTP and decent libraries will save you from dealing with a lot of annoying issues. It's like saving a penny on a 2 penny item. Yes it's 50% but it's still just a penny. No one will be able to tell the difference.
    – JimmyJames
    Commented Sep 29, 2017 at 21:30
  • 1
    And then there are websockets ... Commented Sep 30, 2017 at 6:17

1 Answer 1


This sounds like homework, and in that case you should probably just do whatever is easiest that's in line with what the instructor is expecting. If you want to learn as much as possible, just do it both ways. The reason I bring this up, is that many of the benefits of using HTTP are not going to be evident in a toy example with few real-world requirements.

So why use HTTP as opposed to a plain TCP socket? Paul mentioned one practical concern with regards to firewall traversal. Another practical concern is that there already exist libraries that will handle HTTP communication on both the sending and receiving end. If you use a raw socket you are going to have to solve problems that HTTP or HTTP servers already solve such as breaking the input into discrete messages and demultiplexing the requests. At a more architectural level, by using a standardized, uniform interface, you can layer on functionality that need know nothing about your application. For example, encryption via TLS or caching layers or access control mechanisms or transparent compression.

That said, HTTP isn't usable for everything. HTTP isn't well suited for low-latency, quickly changing, time-sensitive data. Indeed, TCP is often unsuitable for that and UDP-based protocols are used instead. As you allude to, the overhead of HTTP may lead to the metadata dominating the bandwidth for small messages. In most cases this doesn't really matter since you'd need a large number of messages then to lead to bandwidth bottlenecks. HTTP/2 also changes the equation here a bit.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.