Client/Server.Event.MessageReceived or Client/Server.Event.StreamReceived requirement

[Mudoch]

In my recent work I changed all Client sends to server to SendAndWait vs Send. This is a better fit for my needs as all calls to the server must return a result of the message sent. It's a TCP Console app that serves as a data API.

What I noticed is the requirement for either Client/Server.Event.MessageReceived or Client/Server.Event.StreamReceived. Is there a reason for this? Would not Client/Server.Callbacks.SyncRequestReceived also be valid an alternative?

I know I can supply the event callback and just do nothing, it just seems like adding a small bloat to the code when it's never used.

[jchristn]

Hi @Mudoch the early versions of the library didn't have SendAndWait support so setting one of the two was required. The assumption is that most people will use the library with async messaging. For your case, I'd just set an empty handler. If I were to remove the restriction, I feel too many people would find themselves asking "where are my messages going" :) Cheers, Joel