What are the benefits of moving from blocking to non-blocking sockets?

Question

We have an application server developed with Delphi 2010 and Indy 10. This server receives more than 50 requests per second, and it works well. But in some cases, it seems to me that Indy is very unclear. Their components are good, but sometimes I got into the source code to understand the simple. Indy lacks good documentation and good support.
The last thing I came across was a big problem for me: I have to detect when the client disconnects not elegantly (for example, when the client crashes or shuts down without telling the server that it will shut down), and indy was unable to do this. If I want this, I will have to develop an algorithm, for example, heartbeat, pooling or storing TCP. I don’t want to spend more time doing, at least, I think component work. After some research, I found out that this is not Indy's error, but that it is a problem for all the blocking socket components.

Now I really want to change the Server core to another good set. I must admit, I try to use a non-blocking socket. Based on this, I have a few questions:

• What is the advantage of switching from blocking to non-blocking sockets?
• Can I detect client disconnects (not elegant)?
• Which component kit has the best product? For the best product, I mean: fast, good support, good tools and ease of use.

I know this should be a subjective question, but I really want to hear it from you. My first question is the one I like best. I don’t care if I need to pay $ 100, 500, 1000, 10000 dollars, but I want a complete solution. At the moment I am thinking of Ip * works .

EDIT

I think some guys don't understand what I want. I do not want to create my own socket. I have been working with sockets for a long time, and I get tired of it. In fact.

And non-blocking sockets MAY detect client disconnects. This is a fact, and it has good documentation all over the Internet. A non-blocking socket checks the state of the socket for new incoming data all the time, and this allows you to detect that the socket is invalid. This is not a beating algorithm. The heartbeat algorithm is used on the client side and periodically sends packets (aka keep-alive) to the server to indicate that it is still alive.

EDIT

I do not understand. Maybe because English is not my main language. I'm not saying that you can detect a dropped connection without trying to send or receive data from the socket. I say that every non-blocking socket can do this because it is constantly trying to read new data from the socket. Why is it so hard to understand? If you guys download and start ip * demos is running, in special, echoserver and echoclient (both use TCP), you can check it yourself. I have already tested it, and it works as I expected. Even if you use the old TCPSocketServer and TCPSocketClient in non-blocking mode, you will see what I had in mind.

Answer 1

"What is the use of switching from blocking to non-blocking sockets?
Will I be able to detect client disconnects (not elegant)? "

Only my two cents to make the ball roll on this issue - I am not an EXPERT socket, but I have a lot of experience with them. If I'm wrong, I'm sure someone will correct me ... :-)

I assume that since you are using a server using blocking sockets with 50 connections per second, you have a thread mechanism to handle client requests. If so, you really cannot gain anything from non-blocking sockets. On the contrary, you will have to change your server logic to events based on events triggered in the main thread from non-blocking sockets, or use constant polling to find out what your sockets are suitable for.

Non-blocking sockets cannot detect clients, disconnecting without notification, more than blocking sockets - they do not have telepathic powers ... The nature of the TCP / IP "conversation" between the client and server is the same - blocking and non-blocking only occurs when your application interacts with socket connection, leading a "conversation".

If you need to clear dead connections, you need to implement a synchronization or timeout mechanism on your socket (I have never seen a modern socket implementation that did not support timeouts).

Answer 2

What are the benefits of moving from blocking to non-blocking sockets?

Increase speed, availability and bandwidth (in my experience). I had an IndySockets client that received about 15 requests per second, and when I switched directly to asynchronous sockets, the throughput increased to about 90 requests per second (on one computer). In a separate test test on a server in a data center with a 30 Mbps connection, I was able to receive more than 300 requests per second.

Can I detect client disconnects (not elegant)?

This is one thing I haven't had to try yet, since all of my code was client-side.

Which component kit has the best product? For the best product, I mean: fast, good support, good tools and ease of use.

You can create your own socket client in a couple of days, and it can be very reliable and fast ... much faster than most of the things I've seen off the shelf. Feel free to take a look at my asynchronous socket client: http://codesprout.blogspot.com/2011/04/asynchronous-http-client.html

Update:
(According to Mikey comments)

I ask you to get a general technical explanation of how NBS increases throughput rather than a properly designed BS server.

Let's take a server with a high load as an example: suppose your server should process 1000 connections at any given time, with blocking sockets that you would need to create 1000 threads, and even if they are mostly idle, the processor will still spend a lot time to switch context. As the number of clients increases, you will have to increase the number of threads to keep up, and the processor will inevitably increase context switching. For each connection you establish with a blocking socket, you will incur the overhead of creating a new stream, and ultimately you will incur the overhead of cleaning after the stream. Of course, the first thing that comes to mind: why not use ThreadPool, you can reuse threads and reduce the overhead of creating / cleaning threads.

This is how it is done on Windows (hence the .NET connection): you probably could, but the first thing you notice in .NET ThreadPool is that it has two types of threads, and this is not a coincidence: user threads and port threads complete I / O. Asynchronous sockets use I / O completion ports, which "allow a single thread to perform simultaneous I / O on different handles or even simultaneous read and write operations of the same descriptor." ( 1 ) I / O completion port streams are specifically designed to handle I / O in a much more efficient way than you could ever have achieved if you had used custom threads in ThreadPool if you had written your own kernel-mode driver .

"The completion port uses some special voodoo to make sure that only a certain number of threads can start at once - if one thread is blocked in kernel mode, it will automatically start another one." ( 2 )

There are other advantages: "In addition to the non-blocking advantage of I / O with overlapping sockets, another advantage is better performance, because you save a copy of the buffer between the TCP stack buffer and the user buffer for each I / O call." ( 3 )

Answer 3

I have been using Indy and Synapse TCP Libraries with good results for several years and have not found any shoppers in them. I use libraries in streams - on the client and server side, stability and performance were not a problem. (Six thousand requests and responses per second or more with a server running on the same system are typical.)

Blocking sockets are very useful if the protocol is more advanced than the simple "send string / receive string". Non-blocking sockets cause a higher connection between message protocol handlers and socket read / write logic, so I quickly moved away from non-blocking code.

No library can overcome the limitations of TCP / IP regarding loss of connection detection. Only an attempt to read or send data can tell that the connection is still present.

Answer 4

On Windows, there is a third option that overlaps I / O. Non-blocking sockets are important for a model that uses Windows messages designed to make single-threaded GUI applications "locked" while waiting for data. A modern IMHO application would be better designed using streams and overlapping I / O.

See for example http://support.microsoft.com/kb/181611

Answer 5

Aahhrrgghh - the myth of the ability to always detect "fallen" connections. If you press power on a computer with a client connection, the server will not be able to say without sending data that the connection is "dead". This is done through the TCP protocol. Don't take my word for it - read this article ( Discovering Dropped TCP / IP Socket Connections ).

Answer 6

This article explains the main differences between locking and non-locking:

An Introduction to Indy, Chad Z. Waver

Blocking pros

• Ease of programming . Locking is very easy to program. All user code can exist in one place and in sequential order.
• Easy to port to Unix . Because Unix uses blocking sockets, portable code can be easily written. Indy uses this fact to achieve his only source of Solution.
• Work well in threads . Since blocking sockets are sequential, they are essentially encapsulated and therefore very easy to use in streams.

Disadvantages of blocking

• User interface "Freeze" with customers . Blocking socket calls does not return until they reach their task. When such calls are made in the main theme of the application, the application cannot process user interface messages. This causes the user interface to “freeze” because updating, redrawing, and other messages cannot be processed until blocking. Socket call control causes an application message processing loop.

He also wrote:

Blocking is NOT Evil

Blocking sockets are repeatedly attacked without a warrant. Contrary to popular belief, blocking sockets are not evil.

There is no an issue of all blocking sockets components that they cannot detect a client gap. There is no technical advantage on the side of non-blocking components in this area.