Are sockets reliable ?

Question

Is it a good idea to use sockets to send data between two servers, or should I use something like MQ for moving data.

My questions: are sockets reliable, if I need once only/assured delivery of the data?

Are there any other solutions?

Thanks.

Answer 1

Sockets are as reliable as you make your implementation, and based upon the underlying hardware. If you don't want the hassle of making a guaranteed delivery service (under what conditions? 100% is never going to happen), a message queue system is a good bet. The message queue will have implemented all of the persistence, queueing, retries, etc which you would need to implement yourself if you went with standard sockets.

Answer 2

You should probably use an MQ if you need guaranteed delivery no matter what happens (like if the other party goes offline for maintenance) and you don't want to write all the logic yourself. Sockets is what you use to connect to an other party, no matter if that party is the MQ or the final receiver of the message.

Answer 3

Sockets is the raw mechanism for transferring data. Everything else is implemented on top of this. In the OSI network model they belong to layer 4. Although they implement reliable end-to-end connection, they are rarely used as the end protocol. You almost always need to implement an application layer. What this would be depends on your application (do you need to transfer files or just send messages) and your network infrastructure.

Answer 4

If you use a stream socket, the TCP protocol ensures that data does not get lost in transmission and is unlikely to get corrupted (though you have to decide whether its 16bit checksums are sufficient or you need an app-layer checksum mechanism).

What MQ systems provide, and what you may or may not need is application-level transaction-type reliability, i.e. the ability to guarantee delivery even in the face of intermittent hardware or software failures.

Answer 5

Depending on the type of data a simple web service may be the quickest solution. They're relatively easy to set up and test. Though for some specific examples I'd need to know what kind of data and environment you're running.

Answer 6

It depends largly on the type of application you are developing. It you are writing a program where you need response or ack of the message sent then TCP sockets are good. But, if you are implementing some workflow kind of scenario, you should use Message Queues.

Answer 7

Sockets are an application level API for performing network communication. The reliability of sockets depends on the network protocol that you select when you create the socket. If you select TCP/IP, you will get "reliable" transfer ... up to a limit. If you select UDP/IP you will get "unreliable" transfer.

As stated in other answers, TCP ensures that you don't lose or corrupt data up to a point:

1. if there is a long enough network outage, or the sender or receiver dies a TCP/IP connection will break and you will lose data unless you take steps to restart the connection.
2. if there is a network level data corruption, there is a small probability that it won't be detected by the checksums.

For higher levels of reliability guarantees than TCP/IP provides, you need to implement more sensitive checksumming and guaranteed delivery mechanisms over the top of your application's Socket-based networking layer. Or use a message queuing product that does hard the work for you.

So the answer to your question is that it depends on how you use Sockets, and on what level of reliability your system requires.

Answer 8

Socket are reliable since every communication is done on top of it, including MQ.

But you may want to add some garanteed delivery with MQ to improve the reliability of your application. What is it? garanteed delivery ensures that your message is processed at least once, and no more than once, by the consumer. the consumer is off ? the producer is off ? the MQ server is off ? the disk crashes ? thanks to MQ, no message will be lost, whatever happens (provided that your admin knows his job). In addition to that, if you restart the consumer, no message will be processed twice. Wich may be important if the messages contain million dollars transfers. But it does not garantee that your message is processed in a raisonnable amount of time. and processing time is sometime more important that garanteed delivery, depending on your application.

It is up to you to choose the best way to communicate between your servers depending on your needs. Garanteed delivery delivery has both financial and performance cost, so it is to be used only if realy needed (millions dollars tranfers for example).

For most applications you can achieve something satisfying only by retrying your messages when then fail. But that is no real once-only garanteed delivery. don't try to implement it by yourself, it is a very difficult stuff that only few are able to achieve. It is useles to consider redevelopping a software as complicated as MQ or Apache AQ.

Hope that helps.

• jeb