Adi Oanca <adioanca@xxxxxxxxxxxxxx> wrote: > > A while after Adi came on, he found that we needed to have some > > message > > caching on the client side, so the whole PortLink vs Session thing > > came > > about. Pahtz eventually resolved it by integrating both classes > > into > > something which at least in concept would work well. > Yup, in concept. I wonder what happens if I want to transfer a > 10K region? That region will be transfered to app_server, but the > buffer > will remain at 10K ! That's a _bad_ thing as the buffer is too big > for > caching drawing commands and the GUI will be less responsive. It's > enough that the initial buffer has 2K (R5's one is 1K), but 10K is > already > too much! Right, that's also a problem. [...] > > 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(); ? > > 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 Checksum calculation would be as easy as a+b+c (as a message header currently consists out of 3 bytes). > > 4) Synchronous replies need to be possible > As long as there are 2 ports there is no problem. And I think that's the way to go, anyway. The app_server usually knows the reply port. 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) 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 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) d) the response of the server (SERVER_TRUE/SERVER_FALSE) is not significant enough. 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. > 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. But the one evaluating mouse messages shouldn't do any window moving anyway. Right now, the mouse is unusable in VESA modes (when you move a window). Bye, Axel.