[interfacekit] Re: BSession


Hi!

Pahtz wrote:
First, let me summarise the state of affairs as I see it in CVS. Correct me if I'm wrong.
In a moment! :-)

PROTOCOLS

status_t read_port_etc(port_id port, int32 *code, void *buffer, size_t 
bufferSize, uint32 flags,
bigtime_t timeout);

status_t write_port_etc(port_id port, int32 code, const void *buffer, size_t 
bufferSize, uint32
flags, bigtime_t timeout);

The "int32 code" parameter is NOT the BMessage's "what". 
        Nope! It IS! See Looper.cpp's:
                ReadRawFromPort,
                ReadMessageFromPort,
                ConvertToMessage
        methods.
        A system message with no buffer data IS a valid BMessage.

Developers may use it as they wish, but
within the appserver and IK, it represents the message protocol, so we should write 
"int32
protocol". From /headers/private/app/ServerProtocol.h we have these protocols:

AS_SERVER_BMESSAGE - BMessenger/BMessage
AS_SERVER_AREALINK - BAreaLink
AS_SERVER_SESSION - BSession
AS_SERVER_PORTLINK - BPortMessage/BPortLink
The first 2 are not used in the server ATM. BSession is use ONLY by ServerWindow and PortLink is used in the rest.
In the beginning was PortLink, then came along BSession. When Marc finished BPicture implementation, AreaLink appeared. There was a debate why not to use PortLink over BSession, and I and DW had long talks about that. The fact is, PortLink is message oriented and BSession not streamed, and we need that.
At this moment, DW tried to unify all these protocols, but his life went very busy at that moment and he didn't finished it. Because, in his work DW needed PortLink, and me in my work, I needed BSession these protocols ended up independent. That is not bad at all! PortLink is used in the vast majority of cases and BSession is use ONLY between BWindow/BView and ServerWindow.
ATM everything is working just fine with this method in server.
IF, someone tries to unify those will go into serious problems, because of the handler. I mean, if you have a handler that is mainly oriented on PortMessage/PortLink and you send a message with BSession, you will run into BIIIIIG trouble because BSession messages are NOT complete! The other way a BSession handler and sending with PortLink, no problem appears(as you have noticed, in PortLink already there is a method for sending to BSession hander) but a lot of code needs to be modified;
The conclusion we reached: use BSession where you PortLink can't be used: ServerWindow!

AS_SERVER_PORTLINK
And your problem is...?

AS_SERVER_SESSION is a hybrid protocol. Instead of using logical message 
boundaries, it may
fragment on data item boundaries and/or pack more than one logical message into 
the port message.
It is used for communication between BWindow and the appserver where drawing 
instructions could be
numerous and latency could be an issue.
Correct!

Looking at how BSession is used in View.cpp and Window.cpp, it seems to allow 
more than one
logical message to be put into one port call. This makes sense if you have a 
lot of drawing
instructions, an array of lines, or simply wish to avoid the memory management 
and write_port()
overhead of multiple small messages. Sync() is called to then send the bundle 
of messages.
Very much true!

Protocol wise, the int32 'what' code is written, then the data items, then the 
next int32 'what'
code and then the data items. The receiver is assumed to know how many data 
items to expect, and
their type, based on the 'what' code.
Again... correct! Gee you really had your homework! :-)

Looking at the BSession implementation, write_port() is called for the 'what' and each data item.
Where is that you have seen that?

This incurs a high overhead in sending/decoding in the number of port calls. 
The messages are
fragmented to single data items.
High overhead? an automatically write_port() is made for a 1024bytes buffer. "in sending/decoding"? what do you mean?

I don't see the advantage of this since the server shouldn't
execute a command until it has checked all the parameters.
:-))) Wrong! While the client side buffer is filling in (BSession's one) app_server is executing drawing instructions. There is a high probability that, by the time the next write_port() is made and the message reaches the server, the previous commands be already executed.
Eh? What do you say about that? Nice, isn't it?

The degree of parallelism this offers
is insignificant and it causes excessive context-switching.

        Insignificant? Think again! :-)
        Oh, BTW, Be did it this way!

Excessive context switching? Yes... but I would not call it "excessive" - have have a buffer, don't we?

Oh... think if you had PortLink instead of BSession in BWindow/BView? Would you have seen something drawn until BView::Draw() ended? What about if you do a lots of things inside Draw(), how big would have the message been? how long it would have taken for the server to execute instruction found inside? Same is valuable when attaching a large BView tree.

Also BSession had all the return error codes removed. I'm unable to create 
robust software with
it.

void BSession::ReadData( void* data, int32 size );
void BSession::WriteData(const void* data, int32 size);
void BSession::Sync();
Yes, I have added them, then removed. I no longer need them.
a
code = AS_NO_MESSAGE;
ses->ReadInt32(&code)
would tell me if something went wrong. This case... the port has been deleted.
Why do you need to use BSession? it is private!

If we receive multiple logical messages in one port call, and the appserver 
does not recognize the
'what' of the first message, the remaining messages have to be dumped because 
we don't know where
the message boundaries are. What should be the policy here? Should the client 
be disconnected?
No, all datas will be dumped until the next code is recognized.
I know about this... and I had in plan to suffix each instruction with... AS_END_INSTRUCTION.

If there is any deviation in the number or size of data items outside of what 
we expect, the whole
stream becomes out of sync without error detection. We could be reading bogus 
data without knowing
it as missing data is taken from the next message, and extra data becomes the 
head of the next
message.
In 99.99999% of cases this won't happen. Unless a bad user or program will write to a ServerWindow port. I have discussed this with Michael and he said it is not concerned by security.

In anycase, if we decided to have BSession as a streamlined protocol, I suggest 
it be only be used
for non-critical communications, such as drawing instructions. Structural or 
state change messages
should not use this protocol if we tolerate dropping messages in BSession.
Sorry but it is the only one suited for BWindow/BView <-> app_server communication. It worked perfectly until now and I don't see any problems appearing. Hell... Be used it, and look what a nice graphical interface R5 has.

Do we really need BSession?
Yup!

What problem is it meant to solve?
No you have some answers.


Bye,
Adi.



---------------------------------------------------------------
Trimite celor dragi cele mai frumoase felicitari de Paste prin 
http://felicitari.acasa.ro


Other related posts: