[Info-vax] New OpenSSL update from HP

[Jan-Erik Soderholm]

David Froble skrev den 2015-06-17 06:39:
> 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.

OK. Is the telnet server "WEB Services"? Is the SMTP server?

When someone uses a well know name/standard, one expect it also
to actualy be one of those. Not something else.

> 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"?
>

The "web" in "WEB Services" has to do with the fact that this is
built on HTTP as the base protocol. IF you are not using HTTP,
you are (more or less) not using anything "on the web".



> Now, maybe someone has taken it upon themselves to define what is and what
> isn't a "web service".

Note someone. W3C.

> I call bullshit on such.  Our services perform what
> I've understood a web service to be,...

Missunderstandings are common, not only here.

> 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?
>

Childish.

> 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.

Then it isn't "WEB Services".

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

Childish.

Anyway, I just liked to confirm if you actualy used WEB Services
or not. And you don't. That is absolutely fine, of course. I'm not
saying that you should. We do and it have worked "lights out" for
6-7 years now in daily use.

Jan-Erik.