[interfacekit] Re: BSession(NG)

Perhaps lost in the noise but I did supply an example of exactly this. Now it's 
ready for code
review.

http://home.swiftdsl.com.au/~pcky/beos/PortLink.h.txt
http://home.swiftdsl.com.au/~pcky/beos/PortLink.cpp.txt
http://home.swiftdsl.com.au/~pcky/beos/main_PortLink.cpp.txt

I'm thinking of adding in DetachReply(PortMessage *) because it's more 
convenient to pass it on to
dispatch functions for read-only. I'm also devising a transition plan of it's 
adoption.

--- Marcus Overhagen <ml@xxxxxxxxxxxx> wrote:
> Adi Oanca <adioanca@xxxxxxxxx> wrote:
> 
> > Marcus Overhagen wrote:
[...]
> >     Let's hear them!
> 
> Well, basically most of it has been said by me and Ingo.
> 
> The general idea is to use medium sized static buffers, to avoid
> too high latencies in server communication. Small parameters,
> up to a certain size can be passed inline with the message code,
> (for example, region data up to 1 kB), others must be passed in a
> shared area (the application creates it, passes the id to the server,
> and the server deletes it).

You always have the problem of the last message being stuck in the buffer 
waiting for other
messages to push it out or to be Flush()'ed. Also messages can be big or small, 
so buffer size is
actually a poor guarantee of minimum latency. I guess you know this, which is 
why you made the
other suggestion.

> 
> Messages have a fixed maximum size, and start with an opcode
> and a length field. No splitting or reassembly or dynamic buffer
> resizing is done (except creating/deleting areas for large data).
> Receiveing on the server side can also be done into a fixed size buffer.
> Unkown messages can be ignored by the server.

Done.

> When creating a message, parameters must be validated first,
> and if required, the buffer must be flushed first (is should be at least 2/3
> full for the biggest message). Then the full message needs to be written,
> and there would be no support to interrupt that (well, you could remember
> the start position in the buffer, and restore it, if you really need to 
> terminate
> message creation).

see FlushCompleted() and CancelMessage().

> 
> At the end of the BWindow::DispatchMessage() or some other appopriate
> place, the buffer would be always flushed, to insure that all drawing
> calls are executed.
> 
> What remains is to provide a example implementation of this,
> but right now I'm pretty busy, especially with development
> of the Gigabit Ethernet drivers, so I won't do it until requested.
> 
> regards
> Marcus

Cheers,
Paul.



        
                
__________________________________
Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs  
http://hotjobs.sweepstakes.yahoo.com/careermakeover

Other related posts: