[Vortex] vortex_connection_set_receive_handler

Robert M. Münch robert.muench at robertmuench.de
Fri Jan 2 14:41:30 CET 2009

Am 02.01.2009, 12:39 Uhr, schrieb Francis Brosnan Blazquez  
<francis at aspl.es>:

>> 1. Is it enough to implement the VortexReceiveHandler and r
>> VortexSendHandler
> Yes, it is enough because...

Hi Francis, that's good news because it looks quite simple to do.

> 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.

I need to replace the raw socket transport by some other SEND & RECEIVE  
functions I provide.

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

Thanks for clarification.

> 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.

This is where I get confused. To specify different transport mapping I  
need a VortexConnection object. This I can (only?) create by making a  
connection to a beep server using the raw socket transport layer. But what  
is, if I can't reach the beep server via the raw socket transport layer?

I think, I would need a not-connected VortexConnection, than change the  
transport mapping, than initiate a connect to the beep server.

How do I do this? Let I first fail the normal VortexConnection attempt,  
change the transport mapping and than initiate a reconnect?

You speak from a connection reset. What's that and how do I use it?

What exactly is a "tunning profile"?

Best regards.

Robert M. Münch
Mobile: +49 (177) 245 2802

More information about the Vortex mailing list