the delayed error
elch
Hi,
for the freetime of 'low level hackers',
my report about an idea of server communication ( non support request ! )
In the classic 'client-server' model, the client send a request and receives a
response from server - at any time.
Each of these request/response need a whole 'package' to be send, even
commonly less filled with just a few bytes instead max possible ~ 1500 Bytes.
The amount of packages per timespan is limited, so despite fullspeed
communication you see less network traffic.
There is a group of requests, for which the server send an 'ACK' aka: done!
This touches the package limit and further the client have to wait for it.
Best example: update data, aka: REPLACE .. WITH .., lead to billions of ducky
ACK ACK ACK to wait for after each update request. :-)
So i wanted to spare the ACK, but *not to miss* the very rare NO!-ACK.
( example in case: when record not locked )
---
Solution: the client open a second socket to server, at which a second thread
is waiting for incoming info ( reverse the first socket, where the server is
waiting for incoming )
So the server do not send an ACK, but only in case of problem a NO!-ACK to
this second socket. The second thread at client receives it, and prepares a
mutex secured 'global' error object. This is checked by the first thread for
not empty, after each send request ( and when going into idle mode ).
In case of a filled error object, first main thread let runtime error system
pops up with that.
This i named the 'delayed' error :-)
Summa: this lead to a significant performance increase, as client can push out
all these 'data update' requests ( and some other request like UNlock, etc ),
one after another without delay for the ACK, nice filling the queue at server.
In case the client have no MultiThread capability, no second socket is opened,
the server acts 'classic' for this connection, makes ACK ACK ACK :-)
Implemented in LetoDBf ...
elch
