[Libssh] [PATCH 0/2] Add ground to make libssh asynchronous

[Aris Adamantiadis]

Hello Aleksandar,

I am writing a long mail, but it's not a completely personal response, 
see this as a way to put my mind on paper.

A while ago, I though the only good way of having asynchronous and 
nonblocking synchronous libssh calls was to make absolutely all 
functions synchronously non-blocking, returning the different things 
gathered from the communication with the server to the caller 
(ssh_get_message() original implementation is a good example of this 
principle).

But it simply does not scale. The previous model was very confortable 
because it doesn't seem to need a lot of modifications from the previous 
syncronous blocking library, but in fact I was wrong. A tentative was 
made to make libssh nonblocking this way, and it failed.

So, we are now going in an other direction, backed by your patch, of the 
"main loop (client code or libssh code) catches packets and dispatch 
handlers".

Here is how I see that :
User code sees incoming data on the socket. it calls "libssh_process()" 
(or whatever) on the socket.
libssh_process extracts a partial packets and returns, or extracts a 
complete packet. In that case, it calls the handler for that packet.
The packet handler verifies the packet is valid (ie, exists and is 
appropriate). It then creates a message (facultative) and calls a 
message handler.

The message handler can be a built-in handler or a user-provided 
handler. If this handler does not exist (or the user handler returned an 
error code), a default response for this message is generated.

This will induce changes in the way packets are handled right now, and 
move from a sequential point of view (send this, wait for this, send 
this, wait for ack, ...) to a state machine view (we are in the state 
WAITING_PACKET_XXX).

I have yet to find an efficient way of defining user callbacks (i'd 
prefer something which will provide binary compatibility with upcomming 
releases).

Of course, we will continue to provide the simple synchronous functions, 
they will just be wrapped in main loops.

I am open for suggestions for the callbacks.

Best,

Aris

Aleksandar Kanchev a écrit :
> This is a series of patches which add a generic poll support to libssh 
> and demonstrates it's use. It is intended as a ground work for making 
> libssh asynchronous.
> 
> The poll code could be used for:
> 
>     1. Making ssh_bind_listen() and ssh_bind_accept() asynchronous.
>     2. Making the ssh server's authentication asynchronous
>     3. Making ssh_message_get() [packet_read() and packet_write()]
>        asynchronous. That way packets could be dispatched to a proper
>        handler based on their type. For example to open a new channel, to
>        re-initiate kex and so on (similar to OpenSSH's dispatcher).
> 
> regards,
> Aleksandar Kanchev
> 
> 
> 
> _______________________________________________
> Libssh mailing list
> Libssh at cerkinfo.be
> http://www.cerkinfo.be/cgi-bin/mailman/listinfo/libssh
> 

-------------- section suivante --------------
Une pi?ce jointe non texte a ?t? nettoy?e...
Nom: smime.p7s
Type: application/x-pkcs7-signature
Taille: 6657 octets
Desc: S/MIME Cryptographic Signature
Url: http://www.cerkinfo.be/pipermail/libssh/attachments/20090625/cb58e59b/attachment.bin