Since you indicate low traffic volume, maintaining a permanent connection between the server and each client seems to me to be excessive.
Alternatively, I would propose a somewhat different approach. The server should have configuration parameters specifying the maximum number of concurrent connections, the statistical notification interval, as well as other necessary information. The server should maintain a list of all potential clients. Each entry should include a last connection timestamp. Each client should have configuration parameters naming the server, the statistical notification interval, as well as other necessary information. If the server has a task to be distributed to a client for processing, it should examine in client table for an available client, establish an IUCV connection, and transfer to the client the information necessary to initiate the transaction. The connection should then be severed pending transaction completion or an intermediate statistical report. If a connection cannot be established because too many connections are active, the event requirement should be posted for retry after a specified interval. If a connection cannot be established because the client does not respond, some form of recovery (i.e., FORCE/XAUTOLOG) sequence may be appropriate. If a statistical report is required and has not been received by the server, the server should attempt to establish an IUCV connection to the client for that purpose, again following the general procedure outlined above. On the client side, on a regular interval, the client should attempt to establish an IUCV connection to the server for the purpose of reporting statistical information, again following the general procedure outlined above. Maintaining thousands of IUCV connections may not have a significant impact on real storage considering the vast amounts of memory now available on zSeries processors. However, searching through all of those linked lists WILL have a performance impact, and is totally unnecessary. John P. Baker -----Original Message----- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Gary M. Dennis Sent: Monday, August 25, 2008 1:24 PM To: [email protected] Subject: IUCV - What's wrong with this picture? Assumptions: 0. A VM server machine 1. A cluster of client virtual machines (possibly thousands) 2. n buffers are allocated for each client virtual machine 3. Each buffer contains table elements that require (a) Element ageing (b) Element deletion when invalidated by: 1. lack of use 2. client machine request (c) Compression as buffer fragmentation occurs 4. Each client virtual machine in the cluster is connected via IUCV to the server virtual machine. 5. IUCV traffic between the server machine and client machine is extremely low volume. Initial call, termination call, intermittent statistics call. 6. After the initial call, the server virtual machine will maintain the buffer table entries in each client virtual machine without additional IUCV interaction. Now the questions: 1. Does IUCV infrastructure overhead specifically associated with number of connections become prohibitive at some well known point? 2. Has anyone had experience with an application having a high IUCV connection count like this? If so, what was that experience? Again, the traffic incidence per connection is very low but the number of connections is potentially very high. Thanks --. .- .-. -.-- Gary Dennis
