DX Unified Infrastructure Management

I recently learned that for the hub probe in windows systems there is a limit for how many queues it can handle and the limit I found out was 50. This includes permanent and temporary queues. I have asked this question directly from CA and the response was something like that because of Windows Socket implementation there is this limit, but I found the following article from Microsoft : Maximum Number of Sockets Supported (Windows) . In the article it is described that if the winsock provider is Microsoft and the application uses select and WSApoll functions the default limit for concurrent sockets is 64, but this can be increased to the maximum RAM limit of the os installation by defining variables in the application code to a different value.

Can anyone confirm what winsock provider the hub uses? And if the provider is Microsoft can anyone confirm that the issue is due to the functions mentioned above and in the article?

Regards

Pentti Laitinen

Hello Pentti,

I think this article will cover off the information that you are looking for:

https://www.ca.com/us/services-support/ca-support/ca-support-online/knowledge-base-articles.tec000004446.html 

Any questions please let us know. 

Thanks,
Mark

Hello Mark,

What about the article that I linked that says that there is no hard limit on the sockets, but a default value which can be changed by setting certain variables in the program code. I have seen the article you linked before and I don't think it is valid since the article I linked says there is no limit except the RAM amount of the host operating system where the hub is installed. Can you validate if my original question is the actual reason why there is that limit regarding the use of the specific functions?

Regards,

Pentti

The limit in the Windows implementation of the hub isn't the sockets or files, it is because the design of the code relies on the Windows handle function that waits for an event affecting the handle. That call only takes 64 handles at a time. As such as soon as you have more than 64 things (generally speaking this is tunnel sessions and queues combined) for the windows hub to do problems arise. There is supposedly a fall back the windows hub does when the 64 count is exceeded where it moves from an event driven approach to polling but that doesn't seem to work. 

In my experience, with the Windows hub, if you have a structure where you have one queue for each tunnel, you will see instability when you reach 30 active tunnels. And because this is paying attention to sessions, getting 30 tunnels running simultaneously will be a problem and will take 20-30 minutes to settle down each time you restart that hub.

The Unix hub doesn't have access to the windows handle event functionality so it is a little different and you will generally be stable up to 50 tunnels+queues. It relies on the select call to identify when attention is needed and that is limited to 1024 contiguous file descriptors. Each tunnel session and each queue and each open file gets a descriptor and o these get used up pretty fast too.

If you are pushing these boundaries, you will want to use the hub 7.72 release - it's the best behaved.

And at this point, if you are mixing tunnels and queues, I'd recommend doping all your tunnels (at least the server side of them) with a Unix variant. Keep the Windows hubs to queues only.

-Garin

What about the KB article that Mark linked above? In it is stated that it is due to the limitation of open sockets provided by winsock on Windows OS and not the handle limit.

I didn't notice the mention of WaitForMultipleObjects function in the KB earlier.

Hello, Garin. Thank you very much for detailed input. You are correct.

The below is "considerable point" as we've studying through number of large customers.

Place do not more than 30 Tunnel clients in a Windows HUB Tunnel server.

Place do not more than 50 Tunnel clients in a Linux HUB Tunnel server.

Regards,

Yu Ishitani