dcsimg
CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Results 1 to 7 of 7
  1. #1
    Join Date
    Jun 2005
    Posts
    3

    Question Socket Error 10060

    In connection-intensive windows application when performing tests on how many clients may connect simultaneously to a server I got the followin error:

    Unable to read data from the transport connection: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.

    Any ideas what the casue of the error was?
    Thanks.

  2. #2
    Join Date
    Nov 2002
    Location
    California
    Posts
    4,556

    Re: Socket Error 10060

    I apologize for the sarcasm, but do you think that it might be "because the connected party did not properly respond after a period of time" or perhaps "because connected host has failed to respond".

    Seriously, if it's a server like your post suggests, then the problem seems to be the client.

    Mike

  3. #3
    Join Date
    Jun 2005
    Posts
    3

    Re: Socket Error 10060

    Hi Mike,

    I didn't know it was not obvious that this error happened client-side. "...when performing tests..." means I measured server preformance with the help of numerous clients connected (or trying to connect) to it. Maybe my English is not good enough!
    Anyway, it seems to me quite poor performance that a 2.8 MHz machine with 1GB RAM running Windows XP Pro can handle not more than 250 clients at the same time. This happens despite the fact that the thread proc is quite simple - a little more complicated than just re-sending the string received. Threads are blocking (not async calls) and are managed by a thread pool. Initially it seemed that much better performance had to be expected.
    If you (or anybody else) have any suggestions I'll be glad if you share them with me.

    Thanks again.

  4. #4
    Join Date
    Nov 2002
    Location
    California
    Posts
    4,556

    Re: Socket Error 10060

    Quote Originally Posted by achristov
    I didn't know it was not obvious that this error happened client-side. "...
    No, I didnt realize that you were receiving the error client-side. What error (if any) does the server report?

    Quote Originally Posted by achristov
    Anyway, it seems to me quite poor performance that a 2.8 MHz machine with 1GB RAM running Windows XP Pro can handle not more than 250 clients at the same time. This happens despite the fact that the thread proc is quite simple - a little more complicated than just re-sending the string received. Threads are blocking (not async calls) and are managed by a thread pool. Initially it seemed that much better performance had to be expected...
    Tell us a bit more about your testing environment. For example, is this testing performed on a LAN? Wired/wireless? What is the configuration of the clients (multithreaded? blocking?) and are they on multiple different machines or on only one other single machine? Or, perhaps all testing is being performed without a LAN, on the loop-back IP address of 127.0.0.1 from a single machine that hosts the clients and the server?

    Mike

  5. #5
    Join Date
    Nov 2002
    Location
    California
    Posts
    4,556

    Re: Socket Error 10060

    You should also recognize (as you might already) that the single-thread-per-blocking-socket model is the least scalable of all socket models. I might have expected more than 250 simultaneous connections too, given your machine, but how many more is a big question that depends heavily on other drains of resources in the server machine (e.g., what other programs were running there?).

    I came across one source of performance comparisons between the various socket models in "Network Programming for Microsoft Windows, Second Edition", by Anthony Jones and Jim Ohlund, Microsoft Press, 2002. See this Amazon.com link. Chapter 6 discusses scalable Winsock applications for different socket models, and gives the following summary of performance comparisons for them:
    Quote Originally Posted by Chapter 6 "Network Programming For Microsoft Windows, second edition
    Performance Numbers
    This section covers performance numbers from the different servers provided in Chapters 5 and 6. The various servers tested are those using blocking sockets, non-blocking with select, WSAAsyncSelect, WSAEventSelect, overlapped I/O with events, and overlapped I/O with completion ports. Table 6-3 summarizes the results of these tests. For each I/O model, there are a couple of entries. The first entry is where 7000 connections were attempted from three clients. For all of these tests, the server is an echo server. That is, for each connection that is accepted, data is received and sent back to the client. The first entry for each I/O model represents a high-throughput server where the client sends data as fast as possible to the server. Each of the sample servers does not limit the number of concurrent connections. The remaining entries represent the connections when the clients limit the rate in which they send data so as to not overrun the bandwidth available on the network. The second entry for each I/O model represents 12,000 connections from the client, which is rate limiting the data sent. If the server was able to handle the majority of the 12,000 connections, then the third entry is the maximum number of clients the server was able to handle.

    As we mentioned, the servers used are those provided from Chapter 5 except for the I/O completion port server, which is a slightly modified version of the Chapter 5 completion port server except that it limits the number of outstanding operations. This completion port server limits the number of outstanding send operations to 200 and posts just a single receive on each client connection. The client used in this test is the I/O completion port client from Chapter 5. Connections were established in blocks of 1000 clients by specifying the -c 1000' option on the client. The two x86-based clients initiated a maximum of 12,000 connections and the Itanium system was used to establish the remaining clients in blocks of 4000. In the tests that were rate limited, each client block was limited to 200,000 bytes per second (using the -r 200000' switch). So the average send throughput for that entire block of clients was limited to 200,000 bytes per second (not that each client was limited to this amount).

    See Table 6.3 below

    The server was a Pentium 4 1.7 GHz Xeon with 768 MB memory. Clients were established from three machines: Pentium 2 233MHz with 128 MB memory, Pentium 2 350 MHz with 128 MB memory, and an Itanium 733 MHz with 1 GB memory. The test network was a 100 MB isolated hub. All of the machines tested had Windows XP installed.

    The blocking model is the poorest performing of all the models. The blocking server spawns two threads for each client connection: one for sending data and one for receiving it. In both test cases, the server was unable to handle a fraction of the connections because it hit a system resource limit on creating threads. Thus the CreateThread call was failing with ERROR_NOT_ENOUGH_MEMORY. The remaining client connections failed with WSAECONNREFUSED.

    The non-blocking model faired only somewhat better. It was able to accept more connections but ran into a CPU limitation. The non-blocking server puts all the connected sockets into an FD_SET, which is passed into select. When select completes, the server uses the FD_ISSET macro to search to determine if that socket is signaled. This becomes inefficient because the number of connections increases. Just to determine if a socket is signaled, a linear search through the array is required! To partially alleviate this problem, the server can be redesigned so that it iteratively steps through the FD_SETs returned from select. The only issue is that the server then needs to be able to quickly find the SOCKET_INFO structure associated with that socket handle. In this case, the server can provide a more sophisticated cataloging mechanism, such as a hash tree, which allows quicker lookups. Also note that the non-paged pool usage is extremely high. This is because both AFD and TCP are buffering data on the client connections because the server is unable to read the data fast enough (as indicated by the zero-byte throughput) as indicated by the high CPU usage.

    The WSAAsyncSelect model is acceptable for a small number of clients but does not scale well because the overhead of the message loop quickly bogs down its capability to process messages fast enough. In both tests, the server is able to handle only about a third of the connections made. The clients receive many WSAECONNREFUSED errors indicating that the server cannot handle the FD_ACCEPT messages quickly enough so the listen backlog is not exhausted. However, even for those connections accepted, you will notice that the average throughput is rather low (even in the case of the rate limited clients).

    Surprisingly, the WSAEventSelect model performed very well. In all the tests, the server was, for the most part, able to handle all the incoming connections while obtaining very good data throughput. The drawback to this model is the overhead required to manage the thread pool for new connections. Because each thread can wait on only 64 events, when new connections are established new threads have to be created to handle them. Also, in the last test case in which more than 45,000 connections were established, the machine became very sluggish. This was most likely due to the great number of threads created to service the many connections. The overhead for switching between the 791 threads becomes significant. The server reached a point at which it was unable to accept any more connections due to numerous WSAENOBUFS errors. In addition, the client application reached its limitation and was unable to sustain the already established connections (we'll discuss this in detail later).

    The overlapped I/O with events model is similar to the WSAEventSelect in terms of scalability. Both models rely on thread pools for event notification, and both reach a limit at which the thread switching overhead becomes a factor in how well it handles client communication. The performance numbers for this model almost exactly mirror that of WSAEventSelect. It does surprisingly well until the number of threads increases.

    The last entry is for overlapped I/O with completion ports, which is the best performing of all the I/O models. The memory usage (both user and non-paged pool) and accepted clients are similar to both the overlapped I/O with events and WSAEventSelect model. However, the real difference is in CPU usage. The completion port model used only around 60 percent of the CPU, but the other two models required substantially more horsepower to maintain the same number of connections. Another significant difference is that the completion port model also allowed for slightly better throughput.

    While carrying out these tests, it became apparent that there was a limitation introduced due to the nature of the data interaction between client and server. The server is designed to be an echo server such that all data received from the client was sent back. Also, each client continually sends data (even if it's at a lower rate) to the server. This results in data always pending on the server's socket (either in the TCP buffers or in AFD's per-socket buffers, which are all non-paged pool). For the three well-performing models, only a single receive is performed at a time; however, this means that for the majority of the time, there is still data pending. It is possible to modify the server to perform a non-blocking receive once data is indicated on the connection. This would drain the data buffered on the machine. The drawback to this approach in this instance is that the client is constantly sending and it is possible that the non-blocking receive could return a great deal of data, which would lead to starvation of other connections (as the thread or completion thread would not be able to handle other events or completion notices). Typically, calling a non-blocking receive until WSAEWOULDBLOCK works on connections where data is transmitted in intervals and not in a continuous manner.

    From these performance numbers it is easily deduced that WSAEventSelect and overlapped I/O offer the best performance. For the two event based models, setting up a thread pool for handling event notification is cumbersome but still allows for excellent performance for a moderately stressed server. Once the connections increase and the number of threads increases, then scalability becomes an issue as more CPU is consumed for context switching between threads. The completion port model still offers the ultimate scalability because CPU usage is less of a factor as the number of clients increases.
    Attached Images Attached Images  

  6. #6
    Join Date
    Jun 2005
    Posts
    3

    Thumbs up Re: Socket Error 10060

    Thanks, Mike!

    We are working on a C#/.NET based server and we plan to use Macromedia Flash client, which - as you perhaps know - offers something they call XmlSocket. In fact this "beast" does not restrict sends/receives to XML only and unfortunatelly offers only the absolute minimum of functionality, that is it not customizable at all!

    We test on W2003 (2.5+ GHz, 512 MB RAM) server and the client is Windows XP Pro (same config). The tester is written in C# too and available at http://codeproject.com/csharp/testingsocketservers.asp. Only we added few performance counters to it.

    Currently we have the sever implemented the simplest way: blocking listening socket and a dedicated thread from the ThreadPool class for each connection. Obviously, this is the fastest solution but I didn't expect it to perfrom so poorly!

    Your answer helped us espesially the quotation of the book and the table showing the comparisons between different approaches. Since we use a plugin framework (much like OSGi but written in C#) it is easy for us to replace the ineffective plugin with a better performing one leaving the rest of the code unimpaired.

    Thanks for the help again.

  7. #7
    Join Date
    Apr 2018
    Posts
    1

    Re: Socket Error 10060

    At times, the authorization issue can make this error code to popup. If it’s the reason behind it, it’s easy to fix. To do it, open Settings options, and check the box ‘My server requires authentication’. Once done, try to send the email again. It should resolve the socket 10060 error on PC.
    Check this URL
    https://www.errorsolutions.tech/erro...t-error-10060/

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  


Windows Mobile Development Center


Click Here to Expand Forum to Full Width




On-Demand Webinars (sponsored)