[Vortex] ackno in SEQ is not correct?

[Francis Brosnan Blazquez]

> Hi,

Hi Oleg,

> I am having problems to marry beepy and vortex (1.0.12 or the last from CVS).
> 
> The first problem was in beepy's mimeEncode() implementation, I have
> replaced the method.  It took me a step close to have beepy talking to
> vortex.
> 
> The second problem is SEQ messages coming from beepy Initiator (echo
> like client) towards vortex-simple-listener.  Attached log
> (vortex_vs_beepy_local.txt) from listener shows fatal error from
> vortex complaining about SEQ frame has seqno reference value wasn't
> used.  Quick fix in beepy helps to make it work
> (vortex_vs_beepy_remote.txt).  The fix uses remote (vortex listener)
> sequence number rather locally tracked one.
> 
> RFC3081 says in section "3.1.3 Processing SEQ Frames":
> 
> o    an acknowledgement number, that indicates the value of the next
>       sequence number that the sender is expecting to receive on this
>       channel; and,
> 
> My question is about how to make interpretation of RFC3081.  Shall it
> be local number from beepy initiator or remote from vortex listener?
> It is easy fix in beepy however it would be nice to know if vortex
> implementation is correct.

The SEQ frame allows a peer to send a notification about the next
content expected to be received, as you now, pretty much like tcp ACK. 

Looking at the log you have provided it seems that:

1) Beepy sends a message starting a channel:

    MSG 0 1 . 129 134
    Content-Type: application/beep+xml

    <start number="1">
      <profile uri="http://fact.aspl.es/profiles/plain_profile"/>
    </start>
    END

2) Then he sends a SEQ frame like:

   SEQ 0 263 4096

But this is wrong because the beepy side can only ACK the content he
receives but not the content he is sending. At this point, Beepy can
only "ACK" 128 bytes, because it is the only content received. 

3) A the point the vortex side receives the SEQ frame he realize: "..hey
you can't ACK something I didn't sent you...", closing the connection
due to a protocol violation.

The intention with the SEQ frame is to allow the flow control to be
fully supported at the receiving side allowing to stop receiving content
by just stopping issuing SEQ frames....

In other words, as long as I send SEQ frames the remote peer he will be
allowed to send me back more content.

> BTW does anyone interested to have Solaris 8/9 port of vortex and axl?

I didn't...

>  It seems ok however I did some updates preventing crashing of AXL and
> Makefile.in files updates to make it place nice with other compiler
> then gcc, Sun Workshop 6.0 and Sun Studio 11 compilers. 

Nice Oleg. It is good to hear axl and vortex running in more platforms.
In the case you don't know it, you can always use libaxl/test/test_01
and libvortex/test/vortex-regression-{client|server} to check their
function.

>  I need to
> merge updates against CVS version and patch it if anyone would have
> interest.

Sure Oleg. You can post changes to axl here [1]. In the same direction
is usually accepted axl patches and suggestions that are related to
vortex on this lists.

Thanks for reporting!

[1] http://lists.aspl.es/cgi-bin/mailman/listinfo/axl

> Cheers,
> Oleg
> _______________________________________________
> Vortex mailing list
> Vortex at lists.aspl.es
> http://lists.aspl.es/cgi-bin/mailman/listinfo/vortex
-- 
Francis Brosnan Blazquez <francis at aspl.es>
Advanced Software Production Line, S.L.