[Info-vax] Python for x86?

[Arne Vajhøj]

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