[Vortex] vortex_connection_set_receive_handler

[Francis Brosnan Blazquez]

Hi Robert,

> Hi, first I want to wish all a good 2009 and hope that vortex
> development keeps going as in 2008.

Thanks Robert, I wish you the same!

> I want to implement my own send/receive functions using
> vortex_connection_set_receive_handler etc. like the TLS profile does.
> I have looked at the TLS profile code and the docs and have some
> questions about all this stuff:
> 
> 
> 1. Is it enough to implement the VortexReceiveHandler and r
> VortexSendHandler 

Yes, it is enough because..

> or do I have to deal with all the vortext_io_waiting_* stuff as well? 

..vortex_io module is about providing vortex reader with support for
other I/O waiting methods (like poll, epoll).

> The docs state that 
> 
> "Previous handlers must be defined as a whole, it is not possible to
> only define a certain piece reusing the rest of the handlers. If the
> handlers are properly implemented, they will allow Vortex Library to
> perform IO operation with the API you have provided."  
> 
> But it's not clear to me what "previous handlers" means. Only the
> vortex_io_* handlers or all mentioned in the section?

Maybe there are other situations but until now, those handlers
(VortexReceiveHandler and VortexSendHandler) are provided to allow
support for other transport mappings. By default raw sockets are used.
With these handlers TLS is implemented.

> 2. The TLS profile uses a mutex inside the Receive/Send handler. For
> what is this one used? Is it to ensure that there is no race condition
> corrupting the read/write buffers of the SSL stuff? Is it necessary
> that the Receive/Send handler are re-entrant?

The mutex is used because the SSL object is not thread-safe. This is due
to SSL not Vortex.

> 3. What does vortex lib expect as return codes? In the TLS example I
> can see that -1 or -2 is returned in case of an error. Which value do
> I have to return in which cases?

Uhmm.. it is documented but in wrong place. I'll update
VortexReceiveHandler documentation. Return codes are:

N  : utf-8 bytes read from the transport.
-1 : read error (transport mapping error, or some unrecoverable
     condition).
-2 : no data was found or the transport is still not ready to provide 
     data (for example this is used to signal that the TLS handshake 
     hadn't finished yet).

> 4. I thought that a profile is used to put application semantics to a
> channel. TLS is more like a wrapper for normal BEEP communication. Am
> I right that when using TLS, first there is a TLS-ified connection
> made, than the normal BEEP protocol is tunneld through this TLS
> connection? Or is the TLS property only attached to specific channels?

There are two profile types. Both add semantic to your protocol but one
of them do a "tunning" operation. This involves a BEEP connection reset
after successful profile activation.

TLS is a tunning profile. This means that, after successful channel
creation, its effects applies to all channels and the connection is
secured with TLS. 

> What I need to do is, to transparently provide send/receive functions
> to Vortex, without having to patch the library.

I think you have to provide more details to properly answer to this.
Maybe you are looking for implementing a tunning profile (BEEP
connection reset)?

> Best regards.
> 

> _______________________________________________
> Vortex mailing list
> Vortex at lists.aspl.es
> http://lists.aspl.es/cgi-bin/mailman/listinfo/vortex