Replies: 4 comments 11 replies
-
|
Sorry I am being so verbose. A) Possible Use Cases
B) Where I am LeaningI like protobufs + C) Implementation Thoughts
D) Security Thoughts
E) Possible Additional FeaturesThese would be needed for an initial implementation but could be cool.
|
Beta Was this translation helpful? Give feedback.
-
|
(Sorry, I have some exercises in security, and my brain got switched over to that mode of thinking) D1) My thought was checking permissions on startup, and adding a popup to warn against high privilege usage. This would limit the likelihood of something going wrong, and I think is a good idea outside the IPC discussion. D2) Not a big deal. I would consider this more of a port scanning/fingerprinting privacy concern, which could be mitigated via firewall rules (for the few of us who are concerned with it). D3) With TLS-PSK, I would have Supercell-Wx generate a key. This would be unique to your installation. It could then be copied to remote client programs (like an API key would be) providing authentication and confidentiality (unlike an API key). I have done a tiny bit of work with ZeroMQ with GNURadio, but mostly just using other people's code. Let me look into it some more to see what it it can do and how the encryption works. It could be a good choice. I know there are Python libraries as well. |
Beta Was this translation helpful? Give feedback.
-
|
The plugin language would probably need the IPC (the way I was thinking about implementing it). It would make scenes to wait and make it a different discussion. |
Beta Was this translation helpful? Give feedback.
-
|
ZeroMQ looks pretty good. Its messaging eliminates the need to manually encode the length of a protobuf. It supports multiple transports as well. Its IPC transport would probably be good as a start, with TCP as a second option if remote is wanted. The encryption looks usable, but would require having the user manage keys. The only question I have is would it be worth adding the extra dependency if we do not end up adding remote control. |
Beta Was this translation helpful? Give feedback.
-
All good! Security minded is good.
Agreed. It should probably be permanently dismissible, in the event someone is intentional in doing this.
I misunderstood the application. In this case, I think PSK would be just fine. |
Beta Was this translation helpful? Give feedback.
-
|
I don't see any issues in adding the extra dependency, even if it's just for IPC. It's very lightweight. |
Beta Was this translation helpful? Give feedback.
-
|
Just a thought about what a protobuf implementation could look like. It may just be the "new toy" feeling, but I really like protobuf so far. (I use server/client a lot here. Server would be Supercell-Wx) protobufs are not self deliminating, so there will need to be some messaging protocol. If we use a streaming protocol, it could be as simple as sending a length (using something like This idea breaks communications down into "packets". Each request gets a response. For "set" requests, it simply responds with a code and possible error message. For "get" requests it sends the information back on an "OK" response. There are also event packets which can be sent to the client for things such as hot key press. The Obviously there would be more request, response, and event types. This would be broken up into several files. It may be good to keep these files (plus developer documentation) in a separate repo, so that repo can easily be included as a submodule in other projects (either client or server). It may also be worth adding an initial request packet that the client sends to the server with information about itself. That way the user could see what is connected. edition = "2023";
package scwx.proto;
message Panel {
uint32 id = 1;
}
message RadarSite {
string icao = 1;
}
message MapStyle {
string style = 2;
}
message Coordinate {
double latitude = 1;
double longitude = 2;
}
message HotKey {
string combination = 1;
}
message Event {
message HotKeyPressed {
HotKey hot_key = 1;
bool is_repeat = 2;
}
oneof event {
HotKeyPressed hot_key_pressed = 1000;
}
}
message Response {
// Response Codes based loosely on HTTP
enum ResponseCode {
Unknown = 0; // Response code not properly set
OK = 200; // Request successful
Invalid = 400; // Invalid request
Error = 500; // Internal error when processing request.
NotImplemented = 501; // This server does not implement the given request.
}
ResponseCode code = 1; // Response code. Should always be set.
string error_message = 2; // Human readable message describing error for debugging
// request specific data.
oneof data {
RadarSite radar_site = 1000;
Coordinate map_center = 1001;
MapStyle map_style = 1002;
}
}
message Request {
// argument-less gets done via an enum
enum GetCodes {
GetUnknown = 0;
GetRadarSite = 1;
GetMapCenter = 2;
}
message GetMapStyle {
Panel panel = 1;
}
message SetMapCenter {
Coordinate map_center = 1;
bool switch_radar_site = 2;
}
message SetRadarSite {
RadarSite site = 1;
bool center_map_on_site = 2;
}
message SetMapStyle {
Panel panel = 1;
MapStyle style = 2;
}
message SetHotKey {
HotKey hot_key;
}
oneof data {
GetCodes get = 1000;
GetMapStyle get_map_style = 1001;
SetRadarSite set_radar_site = 2000;
SetMapCenter set_map_center = 2001;
SetMapStyle set_map_style = 2002;
SetHotKey set_hot_key = 2003;
}
}
message Packet {
uint32 version = 1;
uint64 request_id = 2;
oneof packet_type {
Response response = 1000;
Request request = 1001;
Event event = 1002;
}
} |
Beta Was this translation helpful? Give feedback.
-
|
I haven't dug my hands into this too extensively yet, but I like what I see. This looks similar to what I did a few years ago toying around with protobuf on a different project (for savefiles rather than messages): I used I think having the data in another repository would be good. It'd make it easier to pin API versions. Is this a repository with just A nice to have would be a sample client as well. |
Beta Was this translation helpful? Give feedback.
-
|
Something like
A sample CLI client would be easy enough to add. |
Beta Was this translation helpful? Give feedback.
-
|
|
Beta Was this translation helpful? Give feedback.
-
|
I think I understand what you are saying now. I see no reason to put the server implementation in a separate repository. I think it would have mainly Name suggestions (I always dislike this part): |
Beta Was this translation helpful? Give feedback.
-
|
What I am thinking now as a first implementation.
Getting working IPC should be the first goal, adding in "plugin" support built on IPC could be worked on later. Remote access, including the decision to include it, should wait. We can get most of the benefits without it. Even using ZeroMQ's encryption, there will still be some discussion about the best way to do key management. ZeroMQ IPC explicitly takes over the socket/pipe/etc when a connection is initialized. This should eliminate problems with leftover stuff from previous runs. It does not deal with having multiple instances of Supercell-Wx running. Simplest solution would be to add the PID to the IPC path, although this may reintroduce cleanup of from previous runs. I would be willing to start working on this once we work out any other details and everything has been reviewed (and maybe wait until location markers part 2 is merged). I would start with the functionality described in the protobuf above and an example CLI client, and get it set up nice enough to be able to add more functions somewhat easily. Edit: decision, not depression. Autocorrect. |
Beta Was this translation helpful? Give feedback.
-
|
I'm trying to consider things way out in the future that may be considered on this one. For instance as just a few examples... be able to include the Radar site name, location, or even what the color pallets are that are being used. If you are able to pull that info into either a graphics util or browser source even... you could create a logo image that could include that data/info. I'm more thinking of a dynamic browser source for a logo overlay in this case. As in when you change to a different radar site, or radar product, the image or browser source could also be updated automatically and on the fly. |
Beta Was this translation helpful? Give feedback.
-
|
(Same reply as on Discord)
|
Beta Was this translation helpful? Give feedback.
-
It may be beneficial for Supercell Wx to have a messaging API. This could allow an external piece of software to interact with Supercell Wx, and synchronize it with others that offer similar functionality.
Message Definition Library (
scwx-messages)This should be a simple library to contain structured message definitions that are supported by Supercell Wx. There should be minimal dependencies. Ideally, this will be packaged as its own repository, so third-party clients can easily incorporate this as a submodule.
Options:
Messaging API Library (
scwx-api)This should be a library that contains the "server" that communicates with clients. It depends on the message definition library. It emits signals to inform
scwx-qtthat it should act. There may be multiple instances of Supercell Wx running at the same time that could all individually receive potentially different commands and requests.The library could have both a client and server implementation. This could simplify usage and encourage adoption. If this is the case, it would not be desirable to use Qt as a dependency.
✅ Local
This approach requires the interacting application to be on the same machine as Supercell Wx.
Backend:
Potential implementations:
❌ Remote
This approach requires access control and information security. Zyre is an option that could be used for discovery.
Signals
Options
Message Handlers (
scwx-qt)There should be message handlers separated into a namespace and folder within
scwx-qtto serve as a central location for handling messages.Beta Was this translation helpful? Give feedback.
All reactions