[Info-vax] Python for x86?

[Dave Froble]

On 4/18/2023 8:10 AM, Arne Vajhøj wrote:
> On 4/17/2023 10:54 PM, Dave Froble wrote:
>> On 4/17/2023 8:00 PM, Arne Vajhøj wrote:
>>> On 4/17/2023 10:17 AM, Dave Froble wrote:
>>>> Gotta say, I'm 100% with Bill on this subject.  Yes, the user knows what is
>>>> needed.  But the user may not understand subtle issues.  Case in point.
>>>>
>>>> In CODIS we've provided what I'll call web services.  May not meet Jan Erik's
>>>> definition of a web services, but they do the job.
>>>
>>> In standard IT industry terminology "web service" is used for
>>> text payloads transported over HTTP(S).
>>>
>>> But I don't think your point depends on whether it is text over HTTP(S)
>>> or binary over plain TCP.
>>>
>>>>                                                            One allowed a
>>>> socket connection to inquire about inventory availability.  Someone setting up
>>>> a web based "shopping cart" could invoke the service to get the availability
>>>> of products.  Now, there is a bit of overhead in the inquiry.  Ask for a
>>>> socket connection, do the handshake stuff, send the inquiry, receive the data,
>>>> and then break down the connection.  One web "programmer" managed to just
>>>> about drag the entire application to a halt.  He was looking for the
>>>> availability of thousands of products.  And so issued thousands of
>>>> connections.  Lots of overhead.  The designer of the web service understood
>>>> what could be needed, and set up the design to allow thousands of products to
>>>> be requested in one connection.  Note, this was well documented.  However, the
>>>> user didn't do the research, just did what he needed, and didn't worry about
>>>> the overall task.  That's what happens when some hacker who doesn't
>>>> understand, or care about, the overall task throws together something.
>>>
>>> I have a very different take on that example.
>>>
>>> If the service documentation said that an argument X
>>> should be 10 characters, the client developer did not read
>>> it and send 12 characters and as a result the server
>>> crashed - then I assume we would agree that it was a
>>> bad design/implementation of the server, because it
>>> should check the length and handle invalid input.
>>
>> That wasn't the issue.
>
> I know. But the issue sounded pretty similar.
>
>>> But the overload situation is really the same. The
>>> server should be prepared for a high request rate and
>>> limit the request rate so the service could not bring
>>> down the server.
>>
>> The server performed adequately.  It was the hacker who complained, and then
>> we had to look at what he was doing.  Then we had to point him to the
>> documentation, which he hadn't read throughly.  It was his stuff that was slow.
>
> Ah. It was the client application that was "about drag the entire
> application to a halt". I read it as the server application.
>
> My mistake.
>
>>> So I think this is a case of the server side being
>>> bad design.
>>
>> No,it worked quite well.
>>
>>> There is a little extra twist here. If the service
>>> had been a standard web service, then it would not
>>> have been necessary to implement the request rate
>>> limit in the service itself. Instead a setup like:
>>
>> Guess you got a problem with apps that work quite well?
>>
>>> client--API gateway--service
>>>
>>> could have been used and the API gateway could
>>> do rate limiting defined in configuration (it could
>>> also do caching, access control and other useful
>>> stuff all defined in configuration).
>>
>> Same result, the hacker would have had poor performance.
>
> I misunderstood the problem.
>
> Arne

Well, maybe I don't explain things well enough ...

:-)

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