Как обмениваться двоичными данными между процессами в Linux

Question

Мне нужно создать приложение linux, которое будет выполнять сканирование беспроводной сети, помещать результат в структуру и каким-то образом отправлять его в другое основное приложение, которое будет использовать данные. Моя первоначальная идея состояла в том, чтобы создать канал в основном приложении, разветвить и запустить execl другой процесс, который может записывать в канал. Примерно так:

pid_t pid = NULL;
int pipefd[2];
FILE* output;
char line[256];

pipe(pipefd);
pid = fork();
if (pid == 0)
{
// Child
  close(pipefd[0]);
  dup2(pipefd[1], STDOUT_FILENO);
  dup2(pipefd[1], STDERR_FILENO);
  execl("/sbin/wifiscan", "/sbin/wifiscan", (char*) NULL);
}

//Only parent gets here. Listen to what the wifi scan says
close(pipefd[1]);
output = fdopen(pipefd[0], "r");

while(fgets(line, sizeof(line), output))
{
//Here we can listen to what wifiscan sends to its standard output
}

Это, однако, не будет работать с двоичными данными, если двоичный 0 появляется на выходе. Поэтому я могу либо отформатировать вывод приложения wifiscan в текст, либо отправить его в pipe и проанализировать в основном приложении, либо сделать это более умным способом, которого я пока не знаю.

Какие существуют другие способы надежного обмена данными между процессами в Linux?

Answer 1

Я подозреваю, что fgets() правильно читает символы NUL, но вы интерпретируете первый как конец прочитанной строки. Это сложно, потому что fgets() предназначен для ввода текста, и он использует '\ 0' в качестве часового, не возвращая количество прочитанных символов. Даже если вы знаете, что каждая строка будет \n завершена, есть вероятность, что необработанные двоичные данные, встроенные в строку, также будут включать \n. Итак, переключитесь на fread(), который предназначен для двоичного файла. Вы можете поместить размер сообщения фиксированной длины (например, 2 байта, 4 байта) в начало каждого сообщения, чтобы другая сторона могла сначала прочитать его, а затем сделать fread() для точного размера сообщения, избегая беспорядочных проблем с частичным сообщение читает.

Если вы действительно хотите сохранить какой-то странный гибрид текста и двоичного кода, вы можете попробовать использовать ftell() после fgets(), чтобы выяснить, насколько далеко вы продвинулись в этом потоке, и, следовательно, в вашем буфере должно быть много символов, но я никогда не видел, чтобы какая-нибудь серьезная система делала что-то столь взломанное

Для записи, не делая чего-то заметно неэффективного, такого как шестнадцатеричное кодирование каждого отдельного символа в двоичных данных, вы можете просто кодировать проблемные символы. Например, можно использовать буквенные escape-последовательности строки C, с \0, представляющим NUL, и \\, с одним \. Хотя визуально проверить это не так просто, программно проще кодировать / декодировать непечатаемые символы, например, используя восьмеричное значение \NNN. Если в нем много непечатаемых символов, то подход с использованием кода uuencode base-64, такой как используемый в почтовых вложениях MIME, является еще одной подходящей, но полностью нечитаемой кодировкой.

Answer 2

Есть много ..

Я бы прочитал Стивенса.

http://www.kohala.com/start/unpv22e/unpv22e.html

Answer 3

Обычно можно использовать fread и fwrite для обмена бинарными структурами между процессами.Он отлично работает для записей фиксированной длины, и нет проблем с отправкой нулей и т. Д.

За свою долгую карьеру я обнаружил, что в большинстве приложений гораздо лучше обмениваться строками ascii, которые легко разбираются (например,scanf) вместо двоичных данных.Таким образом, сообщения можно наблюдать и регистрировать, а отдельные процессы можно тестировать с помощью телнетирования и набора (обычно вставки) в них.Это просто облегчает разработку, если программист может просто читать трафик сообщений.

Answer 4

Надежно обмениваться данными?Это заставляет меня задуматься о библиотеке 0MQ (ZeroMQ): http://zeromq.org

Посмотрите, и в качестве бонуса ваши процессы смогут общаться даже на удаленных компьютерах.

Добро пожаловать воблако.