[interfacekit] Re: BSession


Hi!

Axel Dörfler 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.
Do not worry. In app_server, at a specified place, only one kind of messages arrive (BMessage || BSession_message || PortLink_message)
The unify all idea has been abandoned.

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.
And if this happens, the app should not fail?

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.
I know about it for a long time, but I haven't modified BSession. Lazy me! :-)

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

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.
And manually calculate the byte count of a massage? Don't you think that is a bit... odd and unpractical? Remember that the tail of an instruction may be in another BSession message.

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.
app_server would not die! just one of its threads!



Adi.



---------------------------------------------------------------
Lucram pentru tine. Analizam. Cautam zilnic.
Alegem ceea ce te intereseaza. Te anuntam.
http://www.REDUCERI.ro/


Other related posts: