On Thu, Oct 15, 2009 at 05:26:14PM -0400, Dmitri Pal wrote:
> Hi,
>
> Couple questions about async processing.
> The communication usually consists of several parts. Imagine that you
> have an object that is responsible for some sort of communication
> (socket, pipe, file, bus - whatever).
> Here are the basic things that can happen with such object:
> * Object is created
> * Communication channel is opened
> * Message is sent (and may be you get response back)
> * Communication channel is closed
> * Object is destructed
>
> Object creation and destruction are the same regardless of whether the
> communication is synchronous or asynchronous.
> They are pretty straightforward. So let us talk about the other three.
> Definitely communication on the channel can (and should) be asynchronous
> - this is the whole purpose.
> But what about opening the channel. Should a file or socket be always
> opened as "O_NONBLOCK" or
> the event library would set the flag on the FD itself?
> I guess the question who is responsible for making socket/fd nonblocking
> the creator of it or the async library that provided the event loop?
>
> Now imagine the situation: the opening of the channel includes actually
> two steps, establishing the channel itself (TCP for example) and sending
> some sort of the HELLO message.
> Can this hello message be done synchronously or the connection should
> be established in async way and the hello message should be treated as
> any other message?
> I understand that the preferred way is to do it asynchronously but the
> question is: is it acceptable not to at least in the first implementation?
>
> Same question about closing the channel when this operation involves
> sending some sort of good bye message first. Is it acceptable to send
> and close in one step synchronously or not?
>
> --
> Thank you,
> Dmitri Pal
>
I would suggest to provide special open and close calls. E.g. if you
already have myasync_read_sent(), myasync_read_recv(),
myasync_write_send() and myasync_write_recv() just add myasync_open()
and myasync_close().
If you need to initialize the communication bye sending some HELLO
messages you can provide myasync_myprotocol_init_send() and
myasync_myprotocol_init_recv(). myasync_myprotocol_init_send() will
first call myasync_open() and then myasync_write_sent() with a callback
that does a myasync_read_send() to get the response from the peer. If
there is even more communication needed, e.g. ssl 3way handshake, a new
write/read sequence is started. If the request is finished the result
can be obtained with myasync_myprotocol_init_recv(). Similar for
myasync_myprotocol_teardown_sent() and
myasync_myprotocol_teardown_recv().
The client can now do the following:
msg2server_send()
myasync_myprotocol_init_send()
- callback: msg2server_init_done()
msg2server_init_done()
myasync_myprotocol_init_recv()
myasync_write_send()
- callback: msg2server_write_done()
msg2server_write_done()
myasync_write_recv()
myasync_myprotocol_teardown_sent()
- callback: msg2server_teardown_done()
msg2server_teardown_done()
myasync_myprotocol_teardown_recv()
This way all details are hidden in the myasync_* calls and the client
only need to know that _init_ must be called before _write_.
bye,
Sumit
_______________________________________________
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/sssd-devel
