Francis Brosnan Blazquez
francis at aspl.es
Tue Jan 6 14:27:55 CET 2009
> Hi, I tried to make some steps forward. But I think I hit a blocking
> point. Trying to structure down what I want to do and what I found
> === What do I want to do
> I need to route all Vortex network messages over something like a
> proxy server. For this I have own written send/receive functions that
> work like a socket.
These functions must be configured before any call to vortex_greetings_*
(those I mentioned in my previous reply).
> The connection to the proxy and from the proxy to the BEEP server is
> setup before any Vortex stuff happens. So, TCP/IP connection is
Ok. Here is when you use vortex_connection_new_empty.
> === Things I tried
> 1. To change the transport mapping handlers I need a VortexConnection
> object. So, I need to have a way to create such an object but without
> having it to make any connection.
Ok, so you use vortex_connection_new_empty.
> 2. Tried to get a Vortex connection boot-strapped with an already
> established communication link
> - Using vortex_connection_new with the proxy host/port
> - The connection will fail (as expected) but now I have a
> VortexConnection object to change transport handlers
> - Changed the transport handlers to my function
> - Tried a vortex_connection_reconnect
Here is where you have to use all greetings stuff (BEEP connection
vortex_connection_reconnect won't work on a custom environment like
yours. You'll have to handle it manually.
> The last one doesn't work because vortex_connection_reconnect will use
> the provided host/port values from vortex_connection_new and calls
> __vortex_connection_new which will create an own socket. Thus not
> taking into account that I have provided my own send/receive handlers
> that already can work on an established connection.
> 3. Than I tried using vortex_connection_new_empty to avoid this socket
> stuff. The problem here is, that this function tries to create channel
> 0 before I'm able to specify new transport handlers. I should first be
> able to provide new transport handlers and than have Vortex start all
> this BEEP initializing stuff.
The fact the channel 0 is implicitly created with the connection is not
a problem. It is required to allow BEEP session to work.
Because vortex_connection_new_empty do not make any I/O, there is no
problem. Set up your custom I/O functions after it finishes.
> === Blocking points
> 1. I can't see a way to tell Vortex just to use my handlers (without
> doing any socket stuff) that can already send data back and forth
> 2. I don't see a way to tell Vortex to start the whole BEEP setup
> process like creating channel 0 etc. using the provided send/receive
> handers. These steps are currently hard coded into
> __vortex_connection_new which always creates its own socket. So I
> don't know how to start a new "BEEP initializing without socket
> Any idea how I can solve this?
Take a look on my previous reply to put together all pieces. Cheers!
> Robert M. Münch
> Management and IT freelancer
Francis Brosnan Blazquez <francis at aspl.es>
Advanced Software Production Line, S.L.
More information about the Vortex