[interfacekit] Re: BSession

Adi Oanca <adioanca@xxxxxxxxx> wrote:
> > 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.

If I understood you correctly, that's not really a good idea. There is 
nothing which differentiates between the code and the what field; the 
"what" field might exactly match your special code for a flattened 
BMessage which your code could not handle correctly in this case. Be 
didn't reserve these codes for "what", it's even completely legal to do 
so.

> > 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?

That sounds a lot better :)

> > 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.

How can this make any sense?
There are several possibilities for a port write (or read) to fail, it 
doesn't have to be that the port no longer exists. For example, BeOS 
has a limit of how much memory can be in all ports in the system, this 
is not related to the application.
An even more important thing to consider is B_INTERRUPTED - that can 
happen in all user space code and it should probably be resistant 
against it. However, you're code doesn't even check for B_OK, it only 
checks for one negative case (B_BAD_PORT_ID), that's not just not 
defensive, this is just wrong. 
You should never do that, you must always check for success; there is 
no guaranty that this particular function won't return other error 
codes in the future.

> > 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.

How could this help? What you could do is something similar to what TCP 
is doing: have a packet counter.

> > 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.

If we can do 100% we should do it. This is not "just" a user 
application that would die, this is a system component; the standards 
should be a big higher here.

Bye,
   Axel.

Other related posts: