ERT+CONCIERGEAPI| WEBSOCKET PAYLOAD |
|
about protocol gallery previous downloads team ERT | |
ERT CONCIERGE API | Websocket PayloadsPackets sent from the client to the Gateway API are encapsulated within a gateway payload object and must have the proper operation set.Example{ "operation": "ABCDEFG", ... } ProtocolUpon connecting, the client must send an appropriate IDENTIFY payload within 5 seconds. Otherwise, the connection will be dropped. Any other payload sent during this period will also immediately drop the connection with either:
IdentifyThis payload must be the first payload sent within 5 seconds of establishing the socket connection, else the connection will be dropped. When the concierge receives this payload, it will check that the name does not conflict with the current namespace. If everything goes well, a HELLO payload will be sent to the client. The server versioning should follow semantic versioning.Structure{ "operation": "IDENTIFY", "name": string, "version": string, "secret": string | undefined, } Example{ "operation": "IDENTIFY", "name": "anthony", "version": "0.1.0" } { "operation": "IDENTIFY", "name": "brendan", "version": "0.1.0" } { "operation": "IDENTIFY", "name": "simulation", "version": "0.1.0" } MessageThese payloads have special fields for targeting other users or plugins. The origin fields are ignored if they are sent to the concierge, since the identification process happens per socket. The message is then relayed to the target with an origin receipt field added (overriden by the concierge). The target field must follow one of three possible variants, which are demonstrated below. The NAME and UUID target types will directly pass the message to a single target client. The GROUP target type will broadcast the message to all of the group's subscribers. The data field is transmitted verbatim.Structure{ "operation": "MESSAGE", "origin": { "name": string, "uuid": string } | undefined, "target": { "type": "NAME", "name": string } | { "type": "UUID", "uuid": string } | { "type": "GROUP", "group": string }, "data": any } Example | Payload to the ConciergeImagine that a client identifies as anthony sends this to the concierge.{ "operation": "MESSAGE", "target": { "type":"NAME", "name": "brendan" }, "data": { "foo": "bar" } } Example | Payload from the ConciergeThe user brendan will receive this on their end. Notice that they have an origin receipt attached.{ "operation": "MESSAGE", "origin": { "name": "anthony", "uuid": "..." }, "target": { "type": "NAME", "name": "brendan" }, "data": { "foo": "bar" } } SubscribeSubscribe to a group's broadcasts. The group must exist before anyone can subscribe to it (created using CREATE_GROUP payload). All messages sent to the group will be broadcasted using the MESSAGE payload to the subscribers.Structure{ "operation": "SUBSCRIBE", "group": string } Example{ "operation": "SUBSCRIBE", "group": "simulation1_data" } UnsubscribeUnsubscribe from a group's broadcasts.Structure{ "operation": "UNSUBSCRIBE", "group": string } Example{ "operation": "UNSUBSCRIBE", "group": "simulation1_data" } BroadcastBroadcast to every client connected to the concierge.Structure{ "operation": "BROADCAST", "origin": { "name": string, "uuid": string } | undefined, "data": any } ExamplePayload to the ConciergeImagine that a client identifies as anthony sends this to the concierge.{ "operation": "BROADCAST", "data": { "foo": "bar" } } Payload from the ConciergeThe client brendan (and any other clients) will receive this on their end.{ "operation": "BROADCAST", "origin": { "name": "anthony", "uuid": "..." }, "data": { "foo": "bar" } } Create GroupSubscribe to a group's broadcast.Structure{ "operation": "CREATE_GROUP", "group": string } Example{ "operation": "CREATE_GROUP", "group": "simulation1_data" } Delete GroupUnsubscribe from a group's broadcast. The client that created the group using CREATE_GROUP payload is the only client that can delete the group. The group is also automatically deleted if the owning client disconnects from the concierge.Structure{ "operation": "DELETE_GROUP", "group": string } Example{ "operation": "DELETE_GROUP", "group": "simulation1_data" } Fetch Group SubscribersThis payload asks for all the clients of the group specified in the data field.Structure{ "operation": "FETCH_GROUP_SUBS", "group": string } Example{ "operation": "FETCH_GROUP_SUBS", "group": "users" } Fetch Group ListThis payload asks for all of the groups registered with the concierge.Structure{ "operation": "FETCH_GROUP_LIST" }Fetch Client List This payload asks for all of the clients connected to the concierge. Structure{ "operation": "FETCH_CLIENT_LIST" } Fetch SubscriptionsThis payload asks for the connecting client's subscriptions.{ "operation": "FETCH_SUBS" } HelloThis payload is sent upon successful identification. The payload will also contain a universally unique identifier uuid that acts as a file server key and the version of the server.Structure{ "operation": "HELLO", "uuid": string, "version": string } Example{ "operation": "HELLO", "uuid": "73fcc768-d724-47e2-a101-a45298188f47", "version": "0.1.0" } Group Subscribers ListStructure{ "operation": "GROUP_SUBS", "group": string, "clients": Array<{ "name": string, "uuid": string }> } Example{ "operation": "GROUP_SUBS", "group": "plugins", "clients":[ { "name": "simulation1", "uuid": "..." }, { "name": "simulation2", "uuid": "..." } ] } Group ListThis payload lists all of the groups registered with the concierge.Structure{ "operation": "GROUP_LIST", "groups": Array Example{ "operation": "GROUP_LIST", "groups": [ "simulation1", "simulation2" ] } Client List{ "operation": "CLIENT_LIST", "clients": Array<{ "name": string, "uuid": string }> } Example{ "operation": "CLIENT_LIST", "clients": [ { "name":"simulation1", "uuid":"..." }, { "name":"simulation2", "uuid":"..." }, { "name":"anthony", "uuid":"..." }, { "name":"brendan", "uuid":"..." } ] } SubscriptionsThis payload lists all of the connecting client's subscriptions.Example{ "operation": "SUBS", "groups": Array Example{ "operation": "SUBS", "groups": [ "simulation1" ] } Client JoinA payload broadcasted whenever a new client joins. This is not emitted to newly joining clients.Structure{ "operation": "CLIENT_JOIN", "name": string, "uuid": string } Example{ "operation": "CLIENT_JOIN", "name": "anthony", "uuid": "..." } { "operation": "CLIENT_JOIN", "name": "simulation", "uuid": "..." } Client LeaveA payload broadcasted whenever a new client leaves. This is not emitted to leaving clients.Structure{ "operation": "CLIENT_LEAVE", "name": string, "uuid": string } Example{ "operation": "CLIENT_LEAVE", "name": "anthony", "uuid": "..." } { "operation": "CLIENT_LEAVE", "name": "simulation", "uuid": "..." } StatusStatus payload sent by the concierge. May happen for various reasons such as error response or responses to certain commands.Structure{ "operation": "STATUS", "code": string /* see status codes */, "seq": number | undefined, /* ... */ } Example{ "operation": "STATUS", "code": "OK", "seq": 329 } Status CodesUnless indicated otherwise, these statuses always have a sequence number attached to them. Sequence numbers are based on the n-th text payload received by the concierge. The seq field thus indicates what this status payload is in response to. If the seq field is missing, then it means that this was a status update due to changes not made by the connecting client.
|
API |
_ project lead : santiago v lombeyda _ surf 2020 | efficient network services & new web base client : an tran _ surf 2019 | network services & python realtime app synchronization : alison noyes _ surf 2019 | network services & matlab large data app communication : sasha fomina _ center director : george djorgovski |
_ team |
PROJECT BORN from CALTECH's OVRAS LAB _ with support from the CENTER for DATA DRIVEN DISCOVERY _ with support from Caltech's SUMMER FELLOWSHIP PROGRAM _ with donations from MICROSOFT _ with donations from LOGITECH _ with donations from NVIDIA _ with donations from HTC |
_ acknowledgements |
ovras | OVS | art by jimBARRY | CD3 | caltech | |