[interfacekit] Re: BSession(NG)

Adi Oanca <adioanca@xxxxxxxxx> wrote:

> [Axel, Marcus, Ingo, Marc, DW, Stefano, you don't have anything to say?]
> Erik, Gabe?

Well, I can't catch up with all the messages and rediculous ideas here.

I have done TCP/IP, RS485, BMessage and media kit port based communication
before, and I can assure you that there is really no need to have START and END
codes, reassembly of splitted buffers dynamic resizing of buffers, etc.

I also have some great ideas about how to *optimize* the port link 
communication,
but I didn't want to disturbe app_server development by doing such large changes
(even if they would simplyfiy and most likely speed up the communication)

> > In BSessionNG::WriteData(), the call is not re-startable because the client 
> > doesn't know how much
> > data was sent or left behind.
>       This is easy doable:
>       status_t EndWriteMessage(ssize_t *bytesWritten = NULL);
No need to do that

> > I prefer atomic API calls - either it worked completely, or it
> > didn't at all.
>       The return value of EndWriteMessage() says that.
the most simple form that I described in my other email is atomic.

> > However, if the client decides to abort during building the message there 
> > is no going back because
> > the half built message may have already been sent. BSessionNG called 
> > PrivateSync() behind our
> > back.
>       So what? It's his fault if this happens. There are lot of systems which 
> depend on the Begin() End() paradigm.
You are the implementor (there is no user), and you can make sure that you only 
write
a complete message, or none-

> > Also the user of the class has to try and decide what is the optimal buffer 
> > size to avoid
> > excessive fragmentation but not waste memory. This is hard to guess.
>       Wasn't hard for us! 1024 for BSession, 4096 for PortLink.
>       With proper documentation this isn't hard at all.
Correct. There is no other user that you need to take care of

> > There is the advantage of not having a maximum message size limited by the 
> > kernel port
> > implementation, but we were actually optimizing for small messages. Also on 
> > receiving,
> > EnsureCompleteMessage() allocates memory for the full message so limits 
> > should be enforced
> > somewhere.
>       I do not agree.
Enlarging message buffers is not always a good idea. You might still be 
buffering data,
while the server is running idle. Thus, you introduce latency and effectively 
make drawing
*SLOWER*

> > Perhaps at some point we want to send a BMessage over the same port? Or 
> > forward a
NO YOU WONT.
> > BMessage? I don't know yet.
>       You can't Flatten() send, receive and Unflatten()? :-)
>       But as I said the two serve different purposes.
correct.

Marcus

Other related posts: