Question

I have a server which sends two messages to the client in a row:

require 'socket'
require 'thread'
connections = []
server = TCPServer.new(9998)
loop do
  Thread.start(server.accept) do |client|
    client.print 'Once'
    client.print 'Upon a time.'
  end #eo Thread
end #eo infinte loop

The client is:

require 'socket'
client = TCPSocket.new('localhost', 9998)
2.times { print client.read }
client.close

The client ‘stands suspended’ until I shut down the server, and only then prints out the messages. I know adding client.close to the server would fix the suspension, but I don’t want to close the socket.

I know some applications reuse a TCPSocket. So, it can be Client > Server, Server > Client, Client > Server x2, and so on. I am sure there’s a way to do that in Ruby; I just can’t figure out how.

So, my list of questions is:

1. How do I create a persistant Server <-> Client connection, as described above?
2. Is there a better way of keeping a server open without using loop?
3. Why does it stay suspended like that without client.close in the server? Does the server buffer the messages before it sends them?

Answer 1

1. How does one create a persistant Server <-> Client connection,as described above.

You’ve got several choices: you can write a threaded server, where a single ‘process’ with mostly shared memory executes multiple threads of execution, and each thread has some thread-local storage for e.g. client. Or, you could write a multi-process server, where each client connection gets its own independent process via fork(2) (which pretty much means it runs on Unix-only, as Windows attempts to implement fork(2) never work well). Or, you could write an event-loop based state machine, and use select(2) or poll(2) or epoll(4) to manage which clients are readable, writable, and have errors.

Choosing between them might seem difficult, but there are guidelines available. I’d like to suggest that -small- systems, where you’re only expected to have 20-30 simultaneous clients, can be very well handled via threaded or forked servers. If you wish to go beyond that number of simultaneous clients, you should use a tool like EventMachine or libevent to write your server. (Which may or may not be easier to maintain anyway.)

2) Is there a better way of keeping a server open, without using loop [because I feel like I’ve commited murder by creating an endless loop]

Endless loops are quite fine 🙂 but sometimes it makes sense to offer a way to restart servers or terminate them via signal(7)s or specialized command interfaces.

3) Why does it stay suspended like that without client.close in the server? Does the server buffer the messages before it sends them?

Ah, here is the question you really needed — TCP will try to buffer the results of multiple packets from the server, and due to the potential need to fragment too-large packets mid-route, you, as a client, have no guarantees that any kind of datagram boundaries are preserved.

Chances are very good that your server’s TCP/IP stack waited a tiny bit before sending the first packet to see if more data is coming soon. (It often does.) It probably coalesced the two calls to client.print() into a single TCP packet. Your client calls client.read() twice, but there is probably only enough data for one read. If you wanted your TCP stream to send the first packet immediately, you could look into setting the TCP_NODELAY socket option to disable this small delay. (But it might not help all on its own; you might need to use it in conjunction with TCP_CORK to try to “bottle up” all the writes until you explicitly flush them. This is probably an awful idea.)

A better option would be to re-write your client to be aware of the protocol between your server and client; it needs to read input into a buffer, parse the buffer to find ‘complete messages’, consume those messages, and then return to its main event loop.

Maybe your protocol is to read / write ASCII or UTF-8 terminated with "\n" characters; in that case, you can change print to puts or add the \n in the right places, and change read() to readline(). (This would let the standard IO library handle your protocol for you.) Another approach would be to send data with length+data pairs, and await the correct length of data.