Skip to content
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

Open
danilogr opened this issue Jan 13, 2022 · 4 comments
Open

add a processing callback for comms messages #9

danilogr opened this issue Jan 13, 2022 · 4 comments

Comments

@danilogr
Copy link
Member

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.

@tlsharkey
Copy link
Collaborator

tlsharkey commented Jan 13, 2022

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
    }

}

@tlsharkey tlsharkey mentioned this issue Jan 31, 2022
@tlsharkey
Copy link
Collaborator

Functionality added in 308123f

tlsharkey added a commit that referenced this issue Jan 31, 2022
commit 308123f had some strange extra changes that caused compile errors. That commit was reverted and re-implemented here.
@tlsharkey
Copy link
Collaborator

Implemented in merge #10

@danilogr danilogr reopened this Feb 5, 2022
@danilogr
Copy link
Member Author

danilogr commented Feb 5, 2022

Re-opening to patch the same changes to UnrealiableComm

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants