Axel Dörfler wrote: >>>1) Messages need to be able to be sent on a one-at-a-time basis > What's wrong with: > link.StartMessage(x); > link.Flush(); > ? link.StartMessage(x); link.Attach(&z, 200.000); link.Flush(); What about these messages? BSession would not had a problem. >>>2) Message caching needs to be possible to help with speed in >>>handling >>>BView drawing messages by grouping calls to write_port() >>>3) It shouldn't be possible to just write a random message to any >>>of >>>the server's ports and crash or hang the server >> >> That's not easy doable with current format. > > We can at least easily make it a lot safer. What I am thinking of is > the following and costs 4 bytes with each port write: > - have a special port code; right now, there is AS_SERVER_SESSION and > AS_SERVER_PORTLINK that are used in a non-predictable way > - calculate a checksum over the first message header and place it as > first uint32 in each buffer sent If I send a pachet with a good checksum and malformed data they we're sure for a server crash. > Anyway, I've looked over the messaging, and this is what I think is > problematic: > a) Attach() may fail and cause a partial message to be sent (since we > don't do proper error checking) Where? > b) if the app_server gets a message that needs a reply, but doesn't > know that message (client has a different version, or whatever), the > client will hang instead of receiving an error And that's OK IMO. The client code assumes there's always a valid connection. The client knows eactly what to expect. If something wrong happend it's time to crash. > c) messages tend to be moved in the buffer when you're close to the end > - it would be simpler to just flush the buffer beyond a certain > watermark; that would greatly reduce the need to move messages around > (and also solves the problem with enlarged buffers) IIRC, you got this the wrong way. Messages are gathered in a buffer. Suppose we have 10 bytes left and we have a 20 bytes message to add. BPortLink does not know we have 20 bytes. Add a int, a char, another int and then a 3rd int. At this point it doesn't have anymore space. What it does, is flush the buffer until the start of our message, then moves what we wrote for this message to the start of buffer and then resume attaching data. It resizes the buffer only if a message is greater than buffer's size. > d) the response of the server (SERVER_TRUE/SERVER_FALSE) is not > significant enough. It's not a big deal. The response can be found in message's body. But... do whatever you want. > > If you don't mind I can go over the code and do what I just proposed > over the next few days. > That should make the app_server a lot more robust. Well... if you think so, do it. I, for one, beside the problem with regions I exposed find BPortLink to be quite simple and reliable. Remember, R5 has an even more simpler version and yet I heard nobody complaining about it's stability. >>5) should we group mouse_moved messages that come from input_server? >>If yes, then we need to be able to read all messages present in >>port's >>queue. Current implementation does not allow this. > > It wouldn't be too hard to change, I think. Yet it is, because Read<>() is a blocking call. > But the one evaluating > mouse messages shouldn't do any window moving anyway. But they do. Mouse messages arrive in a RootLayer's port which is responsible for moving windows also. bye, Adi.