[interfacekit] Re: BSession(NG)

Pahtz <pahtz@xxxxxxxxxxxx> wrote:

> If you don't split the message you don't need the packetlist BList structure, 
> and the code is much
> simpler because you don't need to re-assemble the message or use multiple 
> buffers.
If you chose a good static buffer size, that has enough space for the largest 
message,
you don't ever need to split/reassemble messages, or resize buffers.
Example:
Maximum message size it 600 byte. 
Lets make a static buffer that is 2048 (can hold three of the large messages, 
or many smaller ones)
Whenever you want to write a message to the buffer, first check if there is 
enogh space left.
A) if there is, append the message.
B )If there is not, flush the buffer (which might not be completely filled, but 
even in the large message
case it will already be filled 2/3, see above) by doing a write_port. server 
can receive using read_port
into a fixed buffer. write the message to the (now empty) buffer..

> In BSessionNG::WriteData(), the call is not re-startable because the client 
> doesn't know how much
> data was sent or left behind. I prefer atomic API calls - either it worked 
> completely, or it
> didn't at all. But it really doesn't matter since we would abandon the 
> session completely.
You get this with fixed buffer sheme as described above.


> However, if the client decides to abort during building the message there is 
> no going back because
> the half built message may have already been sent. BSessionNG called 
> PrivateSync() behind our
> back.
will never happen

> 
> On the receiving end, StartReadMessage() calls EnsureComplete() so there is 
> no advantage in
> sending half the beginning of a message because it still waits for the 
> complete message. Infact,
> it would mean two read_port() calls instead of one.
not needed 

> Also the user of the class has to try and decide what is the optimal buffer 
> size to avoid
> excessive fragmentation but not waste memory. This is hard to guess. If we 
> say it is the size of
> the largest message, then a small message in the beginning of the buffer will 
> cause the end of the
> large message to end up in the next message. It's partly implementation 
> dependant so I think the
> decision should be done by the class.
See above. There is no "user" involved in using the app server directly. You 
know how large
your largest message is, and you can chose a correct buffer site.

> There is the advantage of not having a maximum message size limited by the 
> kernel port
> implementation, but we were actually optimizing for small messages. Also on 
> receiving,
> EnsureCompleteMessage() allocates memory for the full message so limits 
> should be enforced
> somewhere.
not needed

> ReadData() and WriteData() would have been simple pointer maths and a 
> memcpy(), but now it's a
> while loop with 'slot' management or write_port() inside. I was just going to 
> steal the code from
> PortMessage/PortLink.
too complicated

> If you consider adding DetachCurrent(PortMesssage *) or 
> DetachCurrent(BMessage *) you will realise
> you again it would be simpler without multiple buffer slots to memcpy() or 
> Unflatten() from.
who needs that?

> One way around it is to declare the size of the complete incoming multipart 
> message so you can
> pre-allocate a right-sized buffer. But with partial messages being 
> PrivateSync()'ed out before
> EndWriteMessage() you can't.
that will defeat the whole process of asychronous buffer exchange.

> everyone to use it; BMessage/BLooper system is EXCELENT! I want to keep 
> BSessionNG at its
> simpliest form with all necesities that app_server team needs to have its 
> work done.

> I agree, no bloat. However, I don't understand how 
> BMessage::ConvertToMessage() will be used.

You are bloating this like hell.

Marcus

Other related posts: