[Info-vax] Integrity iLO Configuration?

[Arne Vajhøj]

On 6/25/2021 10:08 PM, Dave Froble wrote:
> On 6/25/2021 7:10 PM, Arne Vajhøj wrote:
>> On 6/25/2021 3:15 PM, Dave Froble wrote:
>>> On 6/25/2021 8:52 AM, Arne Vajhøj wrote:
>>>> On 6/24/2021 6:38 PM, Dave Froble wrote:
>>>>> I need to develop a better method of handling lots of socket connect
>>>>> requests.  I also need to see if my ideas will work Ok.
>>>>>
>>>>> Current thoughts are a single listener that validates requests,
>>>>> accepts the connection, and passes it off to a worker process, then
>>>>> drops it's own connection to the socket.  Involves some inter-process
>>>>> communications.  Listener might get rather busy, but will spend little
>>>>> time on each request.
>>>>
>>>> If you write the listener in a language that supports threading, then
>>>> it could be done relative simple.
>>>>
>>>> client---(TCP)---multi threaded listener---(IPC)---N worker processes
>>>>
>>>> The multi threaded listner has:
>>>> - 1 thread that accepts connections and put them in queue
>>>> - N handler threads that in a loop take connection from queue
>>>>   and does passthrough between client and worker process until
>>>>   client is done
>>>>
>>>> Optionally you could add another tread monitoring queue length
>>>> and handler thread activity.
>>>
>>> If I understand correctly what you suggest, it does not fit what I want.
>>>
>>> Now, it doesn't happen, and I'm not sure why it ever would, but the
>>> listener might have to go down for some reason.  This would kill all
>>> threaded processing, sub-processes, and such.  My desire is to spawn
>>> the worker processes, and they would then be independent of the
>>> listener. While most jobs run very quickly, what about a request for a
>>> report that takes 3 hours to run and then return the result(s)?
>>
>> So the passthrough threads are not good.
>>
>> Could you modify the protocol to work like:
>>
>> * client connect to port N (listener)
>> * listener validates request, determine a free worker process, tell
>>   worker to get ready and tell client to connect to port M
>> * client connect to port M (worker)
> 
> Why would you do all that?

It is a nice model.

Minimal interaction between listener and worker.

>                            A socket can be created with sharing 
> allowed.  Listener grants the connection, worked opens same socket 
> shared, listener closes the socket.
> 
> If the listener peeks into the buffer (not read) it can make decisions 
> based upon what it finds, and the entire socket activity happens in the 
> worker.  Client never knows it is talking to other than the listener 
> that granted the connection.
> 
> At least that's how I understand things, which is why I need to do some 
> research.

The approach is common on *nix (fork).

> The listener/worker communications is where I'm going to have problems. 
> Must be very fast, so listener can be done quickly.

If you accidentally happened to have code for MailBox access
available, then a MB per worker may be a convenient model
and probably fast enough (shared memory is super fast,
but proper synchronization will require more code).

Arne