[Vortex] Using vortex for IPC

[Francis Brosnan Blazquez]

Hi Mikhail,

> I'm trying to use vortex for exchanging large amount of data between
> two processes on the same computer. I have found 2 problems.
> 
>      1. Very low transfer speed (about 20-30 Mb/sec)
> 
> After some changes in vortex I have speed about  100 Mb/sec, and it
> looks much better than 30 Mb/sec.  

Great job Mikhail. At this point, which are the changes introduced? You
can post and describe them?

> I was trying to extend channel window size with
> vortex_channel_set_window_size function, but it was no effect, may be
> because of some bugs and mistakes in vortex. Here are some of them:

Ok. Let's see.

> - max_seq_no_accepted and max_seq_no_remote_accepted from
> VortexChannel inits in vortex_channel_empty_new function 

This is not a bug. This is because BEEP flow control design (based on
SEQ frame [1]). That is, max_seq_no_remote_accepted is the stream of
bytes that is willing to accept the remote side, until *he* send you
back a new SEQ frame extending this value.

[1] http://www.beepcore.org/seq_frames.html

> and doesn't changes their values after vortex_channel_set_window_size.

...and an already notified buffer (the initial 0..4095) can not be
extended until the next SEQ frame is send, that's why
vortex_channel_set_window_size do not change values immediately. Again,
this is not a bug.

Looking at your description it looks like you want to increase the
window size in both sides. You can use vortex_channel_set_window_size
just after vortex_channel_new finish and at the listener side inside the
start handler. 

Once the transfer starts it will quickly become to use your configured
value on the first SEQ frame exchanged (but the first 4096 bytes must be
consumed).

> - vortex_channel_get_next_frame_size always truncates frame size to 4k
> (see code after comment /* use default implementation */)

This is not a bug. This is configurable. Did you try
vortex_connection_set_next_frame_size_handler?

> - sequencer_send_buffer and sequencer_send_buffer_size from VortexCtx
> inits only once in vortex_sequencer_run function and after extending
> channel window size sequencer_send_buffer seems to be too small.

This is not a bug. Take a look on vortex_sequencer_build_packet_to_send
[2]. It dynamically increase the buffer size according to the value
returned by vortex_channel_get_next_frame_size, which is, configurable
via setting a handler that can return your desired value by
vortex_connection_set_next_frame_size_handler.

[2] https://dolphin.aspl.es/svn/publico/af-arch/trunk/libvortex/src/vortex_sequencer.c

> Have anyone some ideas how to fix vortex for extending window size?
> 
>      2. Transfer limit is 2Gb.
> 
> As I understand, the problem is that vortex uses variables of "int"
> type instead of "unsigned int" for saving sequence numbers.  Then the
> transfer size becomes more that 2Gb, vortex tries to increase sequence
> number and it becomes greater than INT_MAX, so  we get sequence number
> value near -INT_MAX. After that vortex closes connection. 

You are right, this is a bug. Reading the RFC it is clear that seq no
values must use unsigned int (2^32 - 1). I'll take a look on this.

> To fix this problem I made a lot of changes in vortex sources (about
> 30 places in 10 files), but I'm not sure that I did all necessary
> changes.  If someone want to fix this bug in vortex, I can send my
> changes to him.

Sure. You can always post your changes to the mailing list. I'll take a
look on them ASAP. 

Thanks for reporting Mikhail. Cheers!

> WBR, Mikhail

-- 
Francis Brosnan Blazquez <francis at aspl.es>
Advanced Software Production Line, S.L.