[Vortex] BUG: Split greetings message aborts connection

[Francis Brosnan Blazquez]

Hi Jens,

> I see your point. But this, then, seems like an awkward limit in the  
> BEEP protocol itself. Since URIs can be of arbitrary length, 

In practice this limit is not a problem since you use profile names to
identify protocols supported. In this context, you won't use arbitrary
lenght strings to identify them.

> and since  
> AFAIK there is no way to announce support for additional profiles  
> after the connection opens, there's an inherent limit on how many  
> profiles a peer can support.

Technically there is not restriction to open a channel under a profile
not announced. For example, assume you have a public BEEP service and
you don't want to provide any detail about services provided until the
user is authenticated. In such context, the initial greetings will only
show SASL and TLS profiles, and then will allow using other profiles. 

This is something we have implemented in turbulence, built on top of
vortex_connection_set_profile_mask.

> (I'm certainly not about to hit that limit, but it's the only hard  
> limit I've seen in the protocol, so I'm surprised.)

;-)

> >> (b) other BEEP implementations are likely to break frames into
> small
> >> chunks, since it's recommended in the RFC, so Vortex will run into
> >> this issue when connecting to those clients.
> >>
> > I don't think so Jens. The RFC talks about MSS (which is usually
> 16K).
> > It never talks about MTU.
> 
> I'm not a TCP expert, but I think you're mixing up MSS with
> something  
> else. My reading indicates that the MSS is the size of the
> underlying  
> transport packet (i.e. for Ethernet ~1500 bytes), minus the size of  
> the TCP headers.
> 
>  From RFC 879 "TCP Maximum Segment Size":
> >    To resolve the ambiguity in the TCP Maximum Segment Size option
> >    definition the following rule is established:
> > THE TCP MAXIMUM SEGMENT SIZE IS THE IP MAXIMUM DATAGRAM SIZE MINUS  
> > FORTY.
> > The default IP Maximum Datagram Size is 576. The default TCP
> Maximum  
> > Segment Size is 536.
> 
>  From
> <http://searchnetworking.techtarget.com/sDefinition/0,,sid7_gci830944,00.html 
>  >:
> >> The maximum segment size (MSS) is the largest amount of data,  
> >> specified in bytes, that a computer or communications device can  
> >> handle in a single, unfragmented piece. [...] When the Internet's  
> >> Transmission Control Protocol (TCP) is used to achieve an
> Internet  
> >> connection, the computers being connected must each agree on, and  
> >> then set, the MTU size acceptable to both. Typical MTU size in
> TCP  
> >> for a home computer Internet connection is either 576 or 1500  
> >> bytes. Headers are 40 bytes long; the MSS is equal to the  
> >> difference, either 536 or 1460 bytes.
> 
> 
> In other words, the BEEP RFC 3081 is recommending that frames be  
> broken into chunks of less than 1kbyte.
> 
> > In general, a BEEP peer that do not use 4k as its default size will
> > behave in an odd fashion (assuming default MSS handle by major
> OSes).
> 
> Remember, I'm not talking about the window size, rather about the  
> maximum size of frame that a message will be broken into.

Obviously I'm mixing real data I'm finding while using APIs that return
current tcp window size negociated [1]. Some initial code I've done on
top of getsockopt using TCP_MAXSEG returns 16K size ;-??¿¿ I've assumed
from this values this the default. This is not correct; thanks for point
Jens.

This requires more digging at the problem since reducing the frame
splitting size down to 1k (I've checked several sizes) shows really poor
performance. 

Cheers!

> —Jens

[1] http://support.microsoft.com/kb/224829
-- 
Francis Brosnan Blazquez <francis at aspl.es>