minor ish c++ request (grpc)

[santa47]

Anyone around that can help me out with a small showeq c project and / or give feedback on high level design?

I've been working on defining an API to split showeq into a frontend and a backend, and have a novel go based backend mostly ready for some more involved testing / showcase (it is currently built to take a quarm live feed and spit out decrypted application packets for the client), but I am not really capable of doing the client side work to tie showeq to the new service. Would anyone be available to throw together a quick skeleton patch to make showeq connect to a grpc backend for its packet feed? I can do most of the grunt lifting, ui work, etc, I just don't really know how to do the thread side of the C work to properly set up a watching client that can take and use the different feeds while properly maintaining state. If someone can show me that bit, I can do the rest of the work myself tying everything together and getting the calls / data points etc updated at least enough for usability.

That said, don't get hung up on this being a replacement server side, it was mostly because I found it far easier to write it this way for myself to handle the Quarm feed, and part of the point of having an api boundary is to make things pluggable / swappable on both sides of the border. I would very much like to have a solid API design agreed on for long term use, but I don't feel strongly about what implementations exist on either side of the equation and am not trying to push this as a replacement backend if that isn't a desired goal.

I have thought about making a very light novel python client or something, but I thought it better to ask here first if someone could do a 30 min job writing a very rough patch for the existing one that I can do the rest of the work on.

The initial backend and an example client in terms of api use can be seen here: https://github.com/nomoresecretz/ghoeq/tree/stream1/
Specifically, the proto / grpc definitions can be found here: https://github.com/nomoresecretz/ghoeq/blob/stream1/common/proto/ghoeq/ghoeq.proto
The server is currently designed for quick and dirty Quarm use, but I plan to switch the data parsing to an opcode vm based system in the next major feature branch, making all the structs / opcodes be able to be updated without recompile (provided there are not new fields at least).


The TLDR of the api as currently designed is the client requests either a raw feed of all the packets seen, or requests to follow a client the backend is tracking. Each independent packet flow is offered as a server side streaming grpc point with a basic dump of the opcode + data portion of the packet for client processing. Longer term I plan to switch to a full protobuf representation of all the structs to hand off instead, but that is not a MVP offering, although hints of it can be seen in the code / proto definitions.

I will admit, part of my reasoning for designing things this way is it becomes *much* easier to just offer a compiled binary for both client and server if this gets adopted, with the caveat that server/stream specific programs would need to be downloaded to handle wire struct layout changes for parsing, but that could be easily automated internally.

[santa47]

I almost forgot, if you've never used gRPC before, its really simple to get going. A quick primer for the c side is here https://grpc.io/docs/languages/cpp/basics/

Basically protoc will generate some glue code behind the scenes, you import it, and start using them as pretty straightforward blocking rpc/function calls along with the generated protobuf objects as well.

[cn187]

I have a private branch where I've started working towards decoupling the capture from the rest of the client, but it's still WIP and not ready for the the light of day.

I can tell you the approach I'm using, though I realize it's not quite in line with how you're looking to do it.

Basically, I've created an abstract base class that has the same interface as EQPacket. A scaled down version of EQPacket still exists as a subclass of the abstract base, so users that still want to use the existing (integrated) capture can. Then I created another subclass to handle spinning up the listener socket, etc. As you would expect, any functionality that's shared between the two (opcode processing, etc.) lives in the base class, and each subclass handles its implementation-specific parts. Then the server just forwards the raw packets to the client, and the client still handles all the packet parsing, opcode dispatch, etc.

[santa47]

Understood. I wish I was strong enough in C to do the work myself considering how much time it would save being able to reuse most of the existing client.

I'll see what I can accomplish along the lines of making a python client side that works similar to the old SINS gui then. My hope is if I make this approachable / maintainable enough in modern languages, I won't be stuck having to fully maintain everything since there doesn't seem to be much interest from the c based showeq team.