[Info-vax] Integrity iLO Configuration?

[Dave Froble]

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?  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 listener/worker communications is where I'm going to have problems. 
Must be very fast, so listener can be done quickly.

>> I learned long ago that when someone tells me "that never happens", it
>> will be one of the first things to bite me on the ass, and therefore I
>> plan for it happening.
>
> Murphy's law.
>
> Arne
>
>


-- 
David Froble                       Tel: 724-529-0450
Dave Froble Enterprises, Inc.      E-Mail: davef at tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA  15486