[Info-vax] Python for x86?

[Arne Vajhøj]

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.

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.

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.

So I think this is a case of the server side being
bad design.

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:

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

Arne