> 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(); Nothing. I was just listing constraints for BPortLink. This one's already covered. :^) > 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). AS_SERVER_SESSION should never be used. It is cruft left over from the BSession vs PortLink debates. There is one unified format, so the only thing we should see is AS_SERVER_PORTLINK. > > > 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. I'm totally in agreement of the recent discussions of utilizing one port for replies. My thought is to have a lock-protected port which belongs to the BPortLink class - a private port_id declared static and protected by a BLocker. Comments? > 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. I've been mulling over how to fix PortLink properly, and there is another issue with PortLink as it is. There are occasions where a message protocol has been changed on one side and not the other, and the client or the server crashes, hangs, or starts using weird data. There needs to be some way to reduce the problems with attachments. Here's what I propose: scrap PortLink for something else which we know works: BMessage, Dano-style. It's a massive changeover, but I think it would also be very much worth it. The original reason for PortLink was a low-overhead messaging class. The reason? All the Flatten() and Unflatten() calls had serious overhead. Be even acknowledged this and changed the format in Dano which used a flattened format to start at the expense of some extra space. If this were the case, we could use a format code just like we do now and the buffer would contain the message. A queueing class could be put together relatively quickly to group write_port calls for BView. Thoughts? > > 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. I don't think that would be a very good idea at this point- there may be effects on responsiveness which are currently unforseen. However, once the messaging subsystem and the app_server are more stable, I wouldn't have a problem with someone at least looking into it. --DW