Re: [boost] Bidirectional streams/archives - Frames

Subject: Re: [boost] Bidirectional streams/archives - Frames
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2010-10-28 08:51:27

----- Original Message ----- 
From: "Jeremiah Willcock" <jewillco_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Thursday, October 28, 2010 12:05 AM
Subject: Re: [boost] Bidirectional streams/archives - Frames

> 
> On Wed, 27 Oct 2010, vicente.botet wrote:
> 
>> Hi,
>>
>> The use I have is to implement binary messages that are user through 
>> protocol stacks. When sending a message, lower layers add usualy headers 
>> and trailers to payload comming from the upper layer. When receiveing a 
>> message, lower layers extract its corresponding headers and trailers 
>> before passing the payload to the upper layer.
>>
>> I'm thinking in generalizing the stream or archive concept, so we could 
>> in addition to been able to read from the begining and write at the end, 
>> been also able to read from the end and write from the begining; a kind 
>> of bidirectional stream or archive.
>>
>> I was thinking in namming the concept "frame", as frames are usualy 
>> composed of header, payload and trailer. Do you have other namming 
>> sugestion? Could this concept have any interest for Boost?
>>
>> Please, let me know if there is already someting on Boost or the 
>> standard library that could help me.
> 
> One thing I would suggest reading is 
> <URL:ftp://ftp.cs.unc.edu/pub/techreports/93-047.pdf>; it describes 
> several systems for managing messages (with headers and trailers) in 
> network protocols.  Especially, you might want to look at the x-kernel and 
> its data structures (see section 3.2 of that report) for messages.  The 
> x-kernel's home page is at 
> <URL:http://www.cs.arizona.edu/projects/xkernel/>; you can get titles of 
> more detailed papers to search for there.
> 
> -- Jeremiah Willcock
 Thanks Jeremiah,

The links you posted explain clearly the context of application.

I have not yet reached to understand why they use a tree of fragments instead of a list to represent a message :(.

In my initial dessign I had frames that have a fixed capacity at run-time and are very efficient when there is enough space in the frame and composite frames (a list of frames) that have unlimited capacity but that are much less efficient. The composite frames are needed to reassamble frames that are seen as a whole frame.

When we need to split a frame on subframes or when we need to preserve a frame to retransmit it, there are two possibilities:
* copy it
* use shared pointers

I need to perform some measures to see when it is better to just copy messages instead of use shared pointers, as the copy should reduce contention. 

Do others have other links to something more recent?

Thanks again,
Vicente