Simpler IPC #907
Simpler IPC #907
Conversation
more robust incoming command parsing get getopt via vcpkg
| json_tokener *parser = s->data; | ||
|
|
||
| size_t processed = 0; | ||
| while (processed < len) { |
There was a problem hiding this comment.
Shouldn't this have some kind of escape-hatch max value? Something like a 1mb or 10 mb? something 'crazy' but not too crazy?
There was a problem hiding this comment.
ipc_cmd_buffered used to use MAXIPCCOMMANDLEN (4096 * 4)
There was a problem hiding this comment.
previous implementation was not correct and would definitely crash if you send over 16K of data
| if (cmd_soc == INVALID_HANDLE_VALUE) { | ||
| DWORD err = GetLastError(); | ||
| fprintf(stderr, "failed to connect to pipe: %lu", err); | ||
| exit(1); |
There was a problem hiding this comment.
are you certain about this particular change with respect to exit-ing? Why is windows the only one that would end up in this situation? Shouldn't the other OS's all exit too in these situations?
This function is much harder to review with all these defines. the old code appears much simpler (just looking at it here, without the IDE) why were these changes needed?
There was a problem hiding this comment.
other OS's would also exit -- just a bit later -- after the write attempt. I'll add the exit on connect
there were multiple callback needed for a simple request/response pattern. which is definitely not simpler
also almost all ziti-edge-tunnel <subcmd> were not working on windows because command parsing was relying on the '\0'/'\n'
simplifies IPC client cli subcommands (tunnel_status, etc) -- simple command/response client does not need an event loop
improves handling of incoming commands - use JSON to determine command boundaries