[Info-vax] Python for x86?

[Dave Froble]

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.

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

> If the first 10 of those 1000 requests took 50 ms each
> and the rest took 500 ms each, then the client developer
> would quickly start reading docs or ask someone.

You got it.  Now try to get some of the hackers to actually read the docs.

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


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