LINUX.ORG.RU

Книга «Linux API. Исчерпывающее руководство»

 ,

Книга «Linux API. Исчерпывающее руководство»

5

2

Добрый день! Предлагаю вашему вниманию книгу «Linux API. Исчерпывающее руководство»(перевод книги The Linux Programming Interface). Ее можно заказать на сайте издательства, и если применить промокод LinuxAPI , то получите скидку 30%.

Отрывок из книги для ознакомления:

Сокеты: архитектура сервера

В этой главе мы обсудим основы проектирования итерационных и параллельных серверов, а также рассмотрим специальный демон inetd, который облегчает создание серверных интернет-приложений.

Итерационные и параллельные серверы

Существуют две распространенные архитектуры сетевых серверов на основе сокетов:

  • итерационная: сервер обслуживает клиентов по одному, сначала обрабатывая запрос (или несколько запросов) одного клиента и затем переходя к следующему;

  • параллельная: сервер спроектирован для обслуживания нескольких клиентов одновременно.

В разделе 44.8 уже был представлен пример итерационного сервера на основе очередей FIFO.

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

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

В следующих разделах мы рассмотрим примеры итерационного и параллельного серверов на основе сокетов интернет-домена. Эти два сервера реализуют упрощенный вариант службы echo (RFC 862), которая возвращает копию любого сообщения, посланного ей клиентом.

Итерационный UDP-сервер echo

В этом и следующем разделе мы представим серверы для службы echo. Она доступна на порте с номером 7 и работает как по UDP, так и по TCP (данный порт зарезервирован, в связи с чем сервер echo необходимо запускать с привилегиями администратора).

UDP-сервер echo постоянно считывает датаграммы и возвращает отправителю их копии. Поскольку серверу нужно обрабатывать только одно сообщение за раз, здесь будет достаточно итерационной архитектуры. Заголовочный файл для серверов показан в листинге 56.1.

Листинг 56.1. Заголовочный файл для программ id_echo_sv.c и id_echo_cl.c

#include "inet_sockets.h" /* Объявляет функции нашего сокета */
#include "tlpi_hdr.h"

#define SERVICE "echo" /* Имя UDP-службы */

#define BUF_SIZE 500 /* Максимальный размер датаграмм, которые
могут быть прочитаны клиентом и сервером */
____________________________________________________________________sockets/id_echo.h 

В листинге 56.2 представлена реализация сервера. Стоит отметить следующие моменты:

  • для перевода сервера в режим демона мы задействуем функцию becomeDaemon() из раздела 37.2;

  • чтобы сделать программу более компактной, мы используем библиотеку для работы с сокетами интернет-домена, разработанную в разделе 55.12;

  • если сервер не может вернуть ответ клиенту, то записывает сообщение в журнал, применяя вызов syslog().

В реальном приложении мы бы, скорее всего, ввели определенное ограничение на частоту записи сообщений с помощью syslog(). Это исключило бы возможность переполнения системного журнала злоумышленником. К тому же не стоит забывать, что каждый вызов syslog() довольно затратный, так как по умолчанию использует fsync().

Листинг 56.2. Итерационный сервер, который реализует UDP-службу echo

_________________________________________________________________sockets/id_echo_sv.c
#include <syslog.h>
#include "id_echo.h"
#include "become_daemon.h"

int
main(int argc, char *argv[])
{
   int sfd;
   ssize_t numRead;
   socklen_t len;
   struct sockaddr_storage claddr;
   char buf[BUF_SIZE];
   char addrStr[IS_ADDR_STR_LEN];

   if (becomeDaemon(0) == -1)
       errExit("becomeDaemon");

   sfd = inetBind(SERVICE, SOCK_DGRAM, NULL);
   if (sfd == -1) {
      syslog(LOG_ERR, "Could not create server socket (%s)",
         strerror(errno));
      exit(EXIT_FAILURE);

   /* Получаем датаграммы и возвращаем отправителям их копии */
   }
   for (;;) {
      len = sizeof(struct sockaddr_storage);
       numRead = recvfrom(sfd, buf, BUF_SIZE, 0, (struct sockaddr *) &claddr, &len);

       if (numRead == -1)
           errExit("recvfrom");
       if (sendto(sfd, buf, numRead, 0, (struct sockaddr *) &claddr, len)
            != numRead)
          syslog(LOG_WARNING, "Error echoing response to %s (%s)",
            inetAddressStr((struct sockaddr *) &claddr, len,
                addrStr, IS_ADDR_STR_LEN),
             strerror(errno));
   }
}
_________________________________________________________________sockets/id_echo_sv.c

Для проверки работы сервера мы используем программу из листинга 56.3. В ней тоже применяется библиотека для работы с сокетами интернет-домена, разработанная в разделе 55.12. В качестве первого аргумента командной строки клиентская программа принимает имя сетевого узла, на котором находится сервер. Клиент входит в цикл, где отправляет серверу каждый из оставшихся аргументов в виде отдельных датаграмм, а затем считывает и выводит датаграммы, полученные от сервера в ответ.

Листинг 56.3. Клиент для UDP-службы echo

#include "id_echo.h"

int
main(int argc, char *argv[])
{
   int sfd, j;
   size_t len;
   ssize_t numRead;
   char buf[BUF_SIZE];

   if (argc < 2 || strcmp(argv[1], "--help") == 0)
      usageErr("%s host msg...\n", argv[0]);

   /* Формируем адрес сервера на основе первого аргумента командной строки */
   sfd = inetConnect(argv[1], SERVICE, SOCK_DGRAM);
   if (sfd == -1)
      fatal("Could not connect to server socket");

   /* Посылаем серверу остальные аргументы в виде отдельных датаграмм */
   for (j = 2; j < argc; j++) {
      len = strlen(argv[j]);
      if (write(sfd, argv[j], len) != len)
         fatal("partial/failed write");

      numRead = read(sfd, buf, BUF_SIZE);
      if (numRead == -1)
         errExit("read");
      printf("[%ld bytes] %.*s\n", (long) numRead, (int) numRead, buf);
   }
   exit(EXIT_SUCCESS);
}
_________________________________________________________________sockets/id_echo_cl.c

Ниже показан пример того, что мы увидим при запуске сервера и двух экземпляров клиента:

$ su              // Для привязки к зарезервированному порту нужны привилегии
Password:
# ./id_echo_sv    // Сервер переходит в фоновый режим
# exit            // Отказываемся от прав администратора
$ ./id_echo_cl localhost hello world  // Этот клиент отправляет две датаграммы
[5 bytes] hello                       // Клиент выводит ответ, полученный от сервера
[5 bytes] world
$ ./id_echo_cl localhost goodbye      // Этот клиент шлет одну датаграмму
[7 bytes] goodbye

Желаю приятного чтения)

>>> Можно купить на сайте издательства



Проверено: alpha ()
Последнее исправление: alpha (всего исправлений: 3)

Ответ на: комментарий от Vinni_Pooh

Единственное что плохо они убрали по сравнению с оригиналом 4 главы по API специфичным для System V

AKonia ★★
()
Ответ на: комментарий от alpha

Леннарт рекомендует

А почему модер провоцирует нездоровые дискуссии? Куда смотрит администрация?!

BceM_IIpuBeT ★★☆☆☆
()
Ответ на: комментарий от hobbit

Автор кстати пишет указывая что это земноводное по его мнению отражает линукс - когда думаешь что разобрался в задаче/теме, оказывается что не так всё просто и подзадачи тоже трудные.

AKonia ★★
()
Ответ на: комментарий от crypt

В смысле зачем? По твоему техническая книга должна быть только на английском? Или что? Оригинал непереводим? Нет такой технической книги которую нельзя перевести. Родной язык читать приятннее.

Вот всегда ржу с таких, надо читать оригинал бла бла бла. Ну ок. Хорошо. Допустим ты прав, вернее вы активисты оригиналачтения.

Тогда по твоему если эммм кореец разработал крутую штуку, но с нюансами которые он раскрывает в своей книге. Он кореец и написал её на корейском. Ты пойдёшь учить их язык? Нет конечно, ты пойдёшь искать перевод, причём перевод на английский ибо типа там всегда самый верный перевод с разных языков.

Вот подумай об этом, я без зла прост подумай, звучит каламбурно и абсурдно, но ведь инглишоменогёрлы часто именно такую подачу затирают. Ну знаешь ты английский, ну хорошо, ну молодец, ну полезно. Но это не значит что иное не нужно.

Вот просто по человечески, со стороны предЪявы к переводам выглядят черезвычайно тупо. Ну правда. Если есть явный косяк перевода который не искажает оригинал, а прям явно вводит в заблуждение то это да. Но… для этого и перевод не нужен, во множестве литературы англоязычной технической встречаются места которые просто тупо друг другу противоречат. А переводы часто убирают/адаптируют словесные обороты и прочий мусор понятный только жителям определённого штата зачем то вписанный в техническое повествование. 100 раз такое видел и главное сносочка (жители Пенсильвании поймут меня, смайлик) и подобное. Читаешь подобное ииии https://www.youtube.com/watch?v=l_--ewb4YXg

anonymous
()
Ответ на: комментарий от hobbit

Многие издательства уже реально прям страшатся пиратов, некоторые книги тираж по 100 штук делают, дабы в минуса не уйти, более того сам наблюдал за последнее время многие некрупные издательства вынудили объединятся или вливаться в большие, а это печаль. А так кстати у лучше бы автор выложил новость про свеже вышедшую книгу «Игровой движок» тоже "Питер"ская, но она прям кладезь знаний для программиста - всё о практике программирования в одной книге.

AKonia ★★
()
Ответ на: комментарий от crypt

У тебя искажённое восприятие мира. Любишь читать оригинал? Наверно больно когда он не английский да? Родной язык лучше любого иного.

anonymous
()
Ответ на: комментарий от anonymous

На самом деле читать на родном языке не только приятнее, но и быстрее, т.к. даже спустя время, опыт чтения англоязычной литературы я не перстал лазить в словари и иногда даже несколько минут втуплять как перевести предложение, но на самом деле я думаю что все «зачем русский», «в оригинале лучше» идут не от объективности(которая иногда имеет место быть), а от банально коллаборации мозга и западнофильства в духе того, что у любой соседки борщ вкуснее, чем у мамы и жены.

AKonia ★★
()
Ответ на: комментарий от AKonia

Да, это пользовательский уровень, где пользователь использует пользовательские интерфейсы предоставляемые ядром.

Именно поэтому книга может быть интересна широкому кругу читателей, а не только писателям драйверов.

alpha ★★★★★
()
Ответ на: комментарий от anonymous

Эммм вы наверное упоролись - каким боком усталело то, что не меняется уже лет 10-15 ? - подсистемы ядра меняются, а пользовательсий API - нет.

AKonia ★★
()
Ответ на: комментарий от anonymous

У них тираж 1000 штук, поэтому пара мамкиных пиратов не попортят спрос, а профессионал в свою библиотеку приобретёт.

AKonia ★★
()
Ответ на: комментарий от AKonia

На самом деле читать на родном языке не только приятнее, но и быстрее

На самом деле нет. И это очень сильно зависит от конкретного текста.

т.к. даже спустя время, опыт чтения англоязычной литературы я не перстал лазить в словари и иногда даже несколько минут втуплять как перевести предложение

Это значит что твой опыт всё-таки недостаточен.

Когда не просто читаешь, а разговариваешь, работаешь на английском переключаться на русскоязычную терминологию дольше.

alpha ★★★★★
()
Ответ на: комментарий от alpha

как раз про драйвера там ничего нет, повторюсь это пользовательский уровень - ты не учишься растить рожь, а лишь собирать и обрабатывать

AKonia ★★
()
Ответ на: комментарий от anonymous

Действительно, уж лучше у того парня с шервуда

GP
()

Год выпуска: 2018

anonymous
()

странно что новость не про Эльбрус

sartakov
()
Ответ на: Вот эта книга? от qbbr

Это скан, слитый в сеть. У него там проблемы с отсутствующими страницами. На складчике не слитый оригинал от издателя

GP
()
Ответ на: комментарий от alpha
  1. Вы не правы, качественный перевод всегда лучше, т.к. думаете вы на русском, хотя после такого пассажа не удивлюсь что вы из тех кто верит что любой код на интерпертируемом языке быстрее оптимизированного кода на си, написанного по грамотно подобранному алгоритму.

  2. Во-первых разговорнаяя/писменная английская речь неплохо так отличаются. Во-вторых полагаю, что как раз ваш опыт достаточно беден, либо читаете вы только текстик по сложности уровня мемов и ответов на SO, т.к. когда сталкиваешься с профессиональной литературой идет постоянное доучивание чужого языка, особенно когда есть тонкости в терминологии и например величинах, традициях и используемых теоремах. В-третьих вполне согласен с тем, что если работаешь в рамках одной узкой области знаний и в основном на чужом языке, то действительно верно, что переключение на русскую терминологию будет проблематичным, особенно если тему/область знаний вы осваивали на другом языке.

AKonia ★★
()

Судя по приведённому фрагменту, не нужно от слова совсем.

Помнится, чтобы завести epoll, мне пришлось тщательно проштудировать маны, несколько статей (причём наиболее информативная называлась «epoll is fundamentally broken»: какая_ирония.jpeg) и ОЧЕНЬ долго экспериментировать и дебажить.

А в приведённом фрагменте «epoll» не упоминается вообще. Глянул по диагонали, какой-то однопоточный блокирующий echo. Кому этот «hello world» нужен? Чему он научит? Назвали бы книгу «Устаревшее Linux API для чайников» – было бы и честно, и интересно: может даже сподвигло бы глянуть на оглавление, чисто поржать.

dimgel ★★★★★
()

Спустя 8 лет перевeли; спустя 10 создали новость на лоре.

anonymous
()

Кроме того, сама постановка вопроса дурацкая, т.к. ставит телегу впереди лошади. Такие книги имели смысл в до-интернетовские времена. А сейчас нормальный человек сначала думает «хочу то-то», затем гуглит как решать, затем уже уточняет конкретные API. Штудировать всё API на случай если вдруг что-то оттуда понадобится – контрпродуктивно.

dimgel ★★★★★
()

Год:2021

так не настал жеж еще. а книга уже вышла. кто-то сломал машину времени

anonymous
()
Ответ на: комментарий от alpha

Когда не просто читаешь, а разговариваешь, работаешь на английском переключаться на русскоязычную терминологию дольше.

Только у тех кто вынужден больше в англоязычной среде быть. Это чисто их проблема и деформация. Если ты активно работаешь как с за рубежом так и в родной среде такой проблемы нет. Более того нет никакой проблемы читать что англоязычные ресурсы что и свои родные и я не про русский я вообще в принципе.

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

Нет мать. Либо ты понимаешь либо нет. Язык тут не причём. И переключаться никуда не нужно, нужно просто знать.

Ах да

Это значит что твой опыт всё-таки недостаточен.

Сильное заявление. Но откровенная лож. Когда есть сообщество и некая среда внутри котрой происходит общение возникает консенсус, как и что говорить как и что куда склонять и прочее. Но это не относится к языку, это относится к способу общения и сужению терминологий, оборотов и в принципе всего. Это да. Но. Даже в пределах одного языка и страны и даже города есть кардинально разные способы подачи мыслей и их фурмулировок.

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

Родной язык физиологически всегда ценнее ибо им у тебя мозг прошит. Ты никогда не научишься думать на другом языке так же легко как на том/тех с которыми ты вырос/ла.

Язык не важен, важно понимание сути, явного и контекста, всё. Когда мы говорим про технические вещи то тут язык лишь частное подмножество для описания и всё. Не важно какой он.

А то что у тебя

работаешь на английском переключаться на русскоязычную терминологию дольше.

Ты извини, но это чисто твои личные проблемы. Ты привыкла общаться по какой то теме в рамках языка и терминов обособленных.

Можно любить иной язык, я не спорю и это замечательно. Но родной язык всегда на голову выше выученного. Если нет.То всё просто ты разучился/лась в родной, вот и всё. Терминология транслитится всегда так было (тысячи лет так слова мигрируют) есть и будет.

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

Удачи и здоровья.

anonymous
()
Ответ на: комментарий от AKonia

Более быстрое усваивание информации на родном языке - как с яблочным пюре - кушать и быстрее и легче.

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

Nervous ★★★★★
()
Ответ на: комментарий от anonymous

кореец разработал крутую штуку, но с нюансами которые он раскрывает в своей книге. Он кореец и написал её на корейском. Ты пойдёшь учить их язык?

Основная общепринятая терминология предметной области все равно на английском, так что лучше читать английский перевод. Меньше придется думать, что хотел сказать автор и больше останется времени на полезное содержимое.

Nervous ★★★★★
()
Ответ на: комментарий от Nervous

По крайней мере, у меня именно такой опыт с русскими переводами технической литературы.

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

anonymous
()

Хотел было купить у них электронный вариант с промокодом - очень неплохая цена, как обед в МакДональдсе на двоих. Я понимаю еще про необходимость email для такой покупки, но… зачем им номер моего телефона при покупке электронной версии и согласие на обработку моих персональных данных? Отказался.

anonymous
()
Ответ на: комментарий от anonymous

Это регрессия и (без обид) деградация владения своим языком

Обидно это признавать, но судя по моим ощущениям это так и есть :(

Удачи и здоровья.

А вообще, качественный пост, брат. Технично и аккуратно макнул Альфу.

anonymous
()
Ответ на: комментарий от AKonia

думаете вы на русском

Может, я и не прав, конечно, но мне кажется, что думаем мы понятиями, а не символами. В родной язык проще их сериализовать, когда понадобится, это да.

Nervous ★★★★★
()
Ответ на: комментарий от Nervous

так что лучше читать английский перевод. Меньше придется думать, что хотел сказать автор и больше останется времени на полезное содержимое.

Эммм, нет. Ну да ладно. Ты просто почему то в это веришь.

Меньше придется думать, что хотел сказать автор

Если ты не понимаешь что хотел сказать автор в переводе с корейского на русский. То с какого перепуга ты вдруг поймёшь что он хотел сказать в переводе с корейского на английский? Ты сам не замечаешь как выдумываешь на ровном месте. Ой я не могу. Ну хватит уже.

anonymous
()
Ответ на: комментарий от anonymous

Если ты не понимаешь что хотел сказать автор в переводе с корейского на русский. То с какого перепуга ты вдруг поймёшь что он хотел сказать в переводе с корейского на английский

Потому что терминология предметной области исходно на английском и весь мир ее понимает одинаково. Когда переводчик начинает переводить термины на русский, очень часто начинается цирк с конями, когда в трех русских переводах один и тот же термин переведен по-своему. Go figure, как говорится.

Nervous ★★★★★
()
Последнее исправление: Nervous (всего исправлений: 1)
Ответ на: комментарий от Nervous

Язык к символам никакого отношения не имеет. Имеют смысл слова стоящие за ними смыслы и понятия, а также из взаимодействия друг с другом включая общий контекст повествования выражаемой мысли. У языка вообще может не быть письменности, но письменность является выражением языка в переносимой форме. Я не про алфавит говорю, я про язык в принципе, но понятное дело что на «бумаге» он выражается в письме. У тебя странные придирки, не имеющие никакого смысла.

anonymous
()
Ответ на: комментарий от dimgel

А сейчас нормальный человек сначала думает «хочу то-то», затем гуглит как решать

Типичный представитель вида «Googlus Stackoverflowis», дамы и господа. Близко к клетке не подходите, если будете давать ему бананы, то только без кожуры, а то он не знает, как их чистить пока не загуглит, а у нас WI-FI барахлит, знаете ли…

goto-vlad
()

Спасибо, купил электронную.

AntonI ★★★★
()
Ответ на: комментарий от anonymous

Имеют смысл слова стоящие за ними смыслы и понятия

Слова (символы) сами по себе смысла не имеют, смысл имеют понятия, на которые эти слова указывают. И как понятия, так и их смыслы не представлены в виде символов, у них свое внутреннее представление. Их не нужно сериализовать (выражать на определенном языке), чтобы ими оперировать (мыслить).

Что яблоко, что apple указывают на одно и то же понятие, которое от языка не зависит.

Мне так думается.

Nervous ★★★★★
()
Последнее исправление: Nervous (всего исправлений: 3)
Ответ на: комментарий от goto-vlad

Гыгы. Про штудирование доки и статей ты благоразумно пропустил. И сам гуглом, надо полагать, не пользуешься. :)

dimgel ★★★★★
()
Ответ на: комментарий от AKonia

Вы не правы, качественный перевод всегда лучше, т.к. думаете вы на русском

Слишком много категоричных неверных утверждений в одном предложении.

Во-вторых полагаю, что как раз ваш опыт достаточно беден

Не надо обижаться на моё замечание и пытаться его развернуть на меня же. Я-то как раз читала книгу из топ-поста в оригинале и без словаря и могу сравнить с предлагаемым переведенным отрывком.

Английский технический язык читается проще.

alpha ★★★★★
()
Ответ на: комментарий от Nervous

Go figure, как говорится.

Ну, если уж про русский говорить то хехехе «вот эта херабора»,«эту херовину» и тому подобное успешно заменяет любую терминологию. Если ты знаешь предмет и контекст. То как бы не назвали что угодно ты понимаешь про что идёт речь. Это юмор, но это правда.

Ну да ладно, хотя да не буду сам топить за то что я тут самый правильный есть такое, если цель унификация то не спорю можно трогать IT исключительно через забугорный, это удобно. Но говорить что он лучше по всем параметрам любого другого языка… пфффффф. Нет.

Подытожу.

  • Не лучше, а хочется, удобнее,вынужден, интереснее или тесть личное предпочтение (про иностранный)
  • Не хуже, а разучились или/и не умели в нужном русле изначально, для многих всё наоборот. (про родной)

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

anonymous
()
Ответ на: комментарий от anonymous

«вот эта херабора»,«эту херовину» и тому подобное успешно заменяет любую терминологию

А потом ракеты падают.

Nervous ★★★★★
()
Ответ на: комментарий от Nervous

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

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.