06.06.2016 12:14, Alex Peshkoff wrote:
> I prefer second solution
So do I and I already start to code.
But in addition to that still the idea to request new plugin only on
definite failure
of old one seems to be good.
--
WBR, SD.
-
On 06/06/2016 01:04 PM, Dimitry Sibiryakov wrote:
> 06.06.2016 11:57, Alex Peshkoff wrote:
>>> May be it worth not to send plugin
name back at all if no plugin switch happen?..
>> Do you want to hide or fix a problem?
> I want to prevent problem when client is switching to other plugi
06.06.2016 11:57, Alex Peshkoff wrote:
>> May be it worth not to send plugin
>> > name back at all if no plugin switch happen?..
>> >
> Do you want to hide or fix a problem?
I want to prevent problem when client is switching to other plugin while
server don't
expect that.
--
WBR, SD.
--
On 06/06/2016 12:43 PM, Dimitry Sibiryakov wrote:
> 06.06.2016 10:18, Alex Peshkoff wrote:
>> Exactly this is not possible. But plugin A can decide that handshake is
>> anyway failed and after it server will load plugin B (next in agreed
>> between server & client list of plugins) and that plugin c
06.06.2016 10:18, Alex Peshkoff wrote:
> Exactly this is not possible. But plugin A can decide that handshake is
> anyway failed and after it server will load plugin B (next in agreed
> between server & client list of plugins) and that plugin can ask for
> more data from client. Answer is expected
On 06/04/2016 12:55 PM, Dimitry Sibiryakov wrote:
> 04.06.2016 11:39, Dimitry Sibiryakov wrote:
>> Server really can order client to use different plugin for continue
>> handshaking?..
> I mean in case of sending op_cont_auth. For example, Srp plugin ask for
> more data and
> wand to get
04.06.2016 11:39, Dimitry Sibiryakov wrote:
>Server really can order client to use different plugin for continue
> handshaking?..
I mean in case of sending op_cont_auth. For example, Srp plugin ask for more
data and
wand to get it from different client plugin. Is it possible at all?..
