-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add a processing callback for comms messages #9
Comments
One way I dealt with customizability on the 3d selection package was to make all of the steps a callback that someone could change. e.g. public System.Action<byte[]> ParseMessageCallback;
private void Awake() {
if (ParseMessageCallback is null) ParseMessageCallback = this.DefaultParseMessageCallback;
}
public void DefaultParseMessageCallback(byte[] data) {
// add to queue
}
public void ListeningThread() {
while (True) {
// listen for data
byte[] data = TCPClient.GetBytes();
// Get full message ...
ParseMessageCallback.Invoke(data); // call the callback
} This way the user can always implement their own version (if they want to setup their own queuing system, or do some more parsing in that thread, they can implement it), but they aren't forced to, because we have our default behavior. So if I want to add my own functionality, I make my own script: public class MessageParser: MonoBehaviour {
public ReliableCommunication Comms;
private void Start() {
this.Comms.ParseMessageCallback = this.HandleData;
}
public void HandleData(byte[] data) {
// do whatever I want
}
} |
Functionality added in 308123f |
commit 308123f had some strange extra changes that caused compile errors. That commit was reverted and re-implemented here.
Implemented in merge #10 |
Re-opening to patch the same changes to UnrealiableComm |
before invoking OnMessageReceived events, Comms should give users the possibility of performing some multi-threaded parsing/decoding.
The goal here is to avoid a 1-2 frame delay for each message that needs to be parsed or decoded in a separate thread.
For example,
if Comms receives a JPG, it then sends it to the main thread during an update call. The update call would then invoke a function that decodes the jpeg in a separate thread. The raw image would only come back to the main thread on the next update call. This guarantees a one frame cost for each frame received.
By allowing users to include custom processing in the socket thread (or in a separate thread), we can receive and decode messages (e.g., JPGs) before calling update with the final result.
The text was updated successfully, but these errors were encountered: