[Info-vax] New OpenSSL update from HP

[David Froble]

Jan-Erik Soderholm wrote:
> David Froble skrev den 2015-06-16 16:35:
>> Simon Clubley wrote:
>>> On 2015-06-15, David Froble <davef at tsoft-inc.com> wrote:
>>>> Simon Clubley wrote:
>>>>> On 2015-06-15, David Froble <davef at tsoft-inc.com> wrote:
>>>>>> Ok, I've never written a web server, yet.  If I was to do so, I'd
>>>>>> seriously look at detached processes rather than sub-processes.  Why?
>>>>>> Because once you assign the worker process a task, perhaps you'd want
>>>>>> it to complete, regardless of whatever the web server does.
>>>>>>
>>>>> What happens if you need to shutdown/restart the web server and need
>>>>> to _guarantee_ that all related processes have terminated as part of
>>>>> of the shutdown process ?
>>>>>
>>>> Couple of issues there.
>>>>
>>>> First, a worker process lifetime should be measured in fractions of a
>>>> second, or a couple seconds at most.
>>>>
>>>> The listener could keep track of the PIDs that it created, and a
>>>> shutdown command could terminate them in the chosen manner.
>>>>
>>>> That said, it's been my impression that web server transactions are
>>>> stateless, (if I understand that term), and usually occur in a rather
>>>> short time period, such as a fraction of a second.  Do you have 
>>>> examples
>>>> of when a worker process would remain active for an extended period of
>>>> time?  I'm curious.
>>>>
>>>
>>> I was responding to the specific technical issues around your desire
>>> to make them detached processes instead of subprocesses.
>>>
>>> Also, connections remain open by default after the initial request has
>>> been completed; these are called persistent connections. See:
>>>
>>>     https://en.wikipedia.org/wiki/HTTP_persistent_connection
>>>
>>> In order to implement this functionality, your detached process would
>>> have to remain around after the initial request has completed and they
>>> would not automatically die (unlike with subprocesses) if the parent
>>> web server process croaked due to some internal bug.
>>>
>>> Simon.
>>>
>>
>> I don't use persistent connections, so don't think about them much.
>> However, if I had a persistent connection, performing some task, and with
>> the connection remaining up, then I'd have to ask, what does the 
>> webserver
>> (or whatever) that initially set up the task have to do with the task
>> completing it's job?  I'd argue that you might want the task to run to
>> completion, regardless of what the web server (or whatever) is doing.  
>> I'll
>> also admit that the design of each application may have different
>> requirements.
> 
> Note that "HTTP persistent connections" is only talkning about the main
> connection between the client and the server. It has nothing to do with
> possible persistent server processes. That are two different things.
> 
> 
>>
>> Now, if a particular application had the requirement that if a "master"
>> process failed then all worker processes must exit, regardless of the 
>> state
>> of any transactions they might be working on, then there is more than one
>> way of accomplishing that.  For example, keeping a list of assigned or
>> active PIDs and STOP/ID= can be a rather large hammer, one that even
>> handles non-responsive processes.
>>
>> As for why detached processes might be better, consider the application
>> design where once a task is assigned, you might need it to run to
>> completion, regardless of whatever happens to whatever started the 
>> task? In
>> that case, as you indicate, a sub-process does not have such a guarantee.
>>
>> One size doesn't fit all.
>>
>> AS I have been designing and implementing web services for some time 
>> now, I
>> think I have a decent understanding of the issues.
> 
> I have not really understood if you actualy have implemented what
> generally is regarded as "WEB Services".
> 
> https://en.wikipedia.org/?title=Web_service
> http://www.w3schools.com/webservices/
> 
> Do you use WSDL files and SOAP data format?
> 
> Or if you have some more simple listener on an IP port using
> an homegrown data format and just calling that "web services".
> 
> It looks like you are not running a WEB Services setup.

What's in a name?

We have services set up that listen for connection requests.  When a 
connection request arrives, the service connects, reads the incoming 
data, if it's something expected it then performs the required task and 
sends the required response to the client.  On the internet.  Or should 
I say "on the web"?

Now, maybe someone has taken it upon themselves to define what is and 
what isn't a "web service".  I call bullshit on such.  Our services 
perform what I've understood a web service to be, and if someone else 
doesn't like our protocols, well, I'll define our protocols to be the 
only "true web service protocols", and we're basically even.  If someone 
else can define acceptable protocols, then why can't I?

No, we do not use WSDL, SOAP, XML, and the rest of that crap.  We've 
looked at it, and don't see any valid use for it.  It's just a bunch of 
bloat and overhead.

Maybe I'm a bit touchy on the subject, but, I'm getting tired of 
everyone else being in charge of things.