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
> 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"?
Robert M. Münch
Mobile: +49 (177) 245 2802
More information about the Vortex