Hi,

true, the input is being buffered as long as the connection is open. This was a design decision rather than a bug, the reason being that one can't rely on the TCP buffer size used by the remote sender, hence if the remote sender is trying to send data that is bigger than the remote TCP buffer, then the data will arrive in multiple subsequent TCP packages. As the input is buffered, these chunks would be merged automatically by the receiver so that the end-user wouldn't need to take care about this.

On the other hand, you're absolutely right, this requires the closing-and-reopening of the connection after each sent message if buffering them is not an option for you, which generates unnecessary network overhead. I am working on a bidirectional TCP server object for a while which will give a good alternative, but never got to the point when I could have considered it done.

Alternatively, I could also add a flag to the object where the user could turn off buffering in the next release of the library (which won't happen in the very near future, but I'm expecting to make an update soon -- there are already two new objects and some bug fixes waiting to be published).

Hope that helps, Ádám

Buffering is not an option --- I want to send fader changes from a touch surface.