Hi Mattias,
Thanks for the input and clarification. I will include these changes in
the v6.
Regards,
Kevin
On 22/10/2018 08:11, Mattias Rönnblom wrote:
On 2018-10-19 12:16, Laatz, Kevin wrote:
On 03/10/2018 20:06, Mattias Rönnblom wrote:
On 2018-10-03 19:36, Kevin Laatz wrote:
From: Ciara Power <ciara.po...@intel.com>
+
+ if (!telemetry->request_client) {
+ TELEMETRY_LOG_ERR("No client has been chosen to write to");
+ return -1;
+ } > +
+ if (!json_string) {
+ TELEMETRY_LOG_ERR("Invalid JSON string!");
+ return -1;
+ }
+
+ ret = send(telemetry->request_client->fd,
+ json_string, strlen(json_string), 0);
How would this code handle a partial success (as in, for example,
half of the string fits the socket buffer)? In not, maybe switching
over to a SOCK_SEQPACKET AF_UNIX socket would be the best way around
it.
Is the suggestion here simply to use socket(AF_UNIX, SOCK_SEQPACKET)
instead of (AF_UNIX, SOCK_STREAM) ?
That would be the most straight-forward to the problem, I think.
Linux' SOCK_SEQPACKET implementation has problems with really large
messages (since a per-message linear buffer is allocated), but I'm
guessing these messages are not in the hundreds-of-kb range.
+
+ buffer_read = read(telemetry->accept_fd, buf, BUF_SIZE-1);
This and the below code seem to assume that read() returns one and
only one message, but on a SOCK_STREAM, there is no such thing as a
message. It's a byte stream, and you need to provide your own
framing, or have an application protocol which allows only have one
outstanding request. If you do the latter, you still need to allow
for "short" (partial) read()s (i.e. re-read() until done).
Will the above solve this part of the problem too?
Yes. The kernel will delivered the application (at most) one message,
in its entirety.
