On 7/5/21 6:28 PM, Jiří Činčura wrote:
What's the expected response to server from client after client
receives op_accept_data?
It's a weird combination I'm doing and something is missing from my
implementation here.
Client:
Srp256, Srp
WireCrypt: Disabled
CNCT_specific_data sent for Srp256.
Server:
Srp
When the WireCrypt is Enabled (on client) then the first response after
op_attach is op_cond_accept and the dance with op_cont_auth can start. But with
WireCrypt Disabled (on client) the op_accept_data is the first response.
Really. We care about final state of line encryption. Depending upon
config on server & client (required/enabled/disbaled) there may be 3
results - enabled, disabled or reject connection. When encryption is
enabled we must proceed with authentication _before_ sending to server
sensitive data like dbname or dpb. Therefore op_cont_auth is used until
auth completion and encryption initialization before op_attach.
With disabled state of line encryption we can proceed with op_attach
before authentication completion, saving one roundtrip from server to
client. After op_attach some more roundtrips with
op_cond_accept/op_accept_data (processing of them on client does not
differ, they arrived historically) on success you get op_response with
success - that means working connection with server.
And I'm having trouble figuring out what's next.
It's rather hard to say "after packet A follows packet B". That may
depend upon configuration, details of user's attach request, server
response, etc. 4 things need to be done - authentication, attach,
encryption init & compression init. Some of them I try to do in parallel
(i.e. saving roundtrips) when possible - but do not pretend to be ideal
from this POV.
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
