Разработка TCP-сервера: схема обработки потока байт

final state machine. и передаёшь/принимаешь не структуры, а поток байт.

final state machine

по-русски, обычные конечные автоматы?

У меня получается такая схема:
1) хранить указатели на начало/конец принятых байт и номер состояния стейт-машины для каждого соединения в массиве соединений (25-50к штук);
2) запросы от каждого клиента (сокета) записывать в общую очередь, бегать по очереди и удалять при завершении выполнения;
3) состояние буферов отдачи хранить в элементе очереди, соответствующему запросу.

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

где-то так, только вместо массивов, советую посмотреть на queue.h

советую посмотреть на queue.h

Уже использую.
Кстати, они не тормозят? Реализация queue.h через malloc()?

а чему там тормозить? это чистые макросы. что на вход подашь, то и будет.

по скорости они конечно все слегка отличаются друг от друга. (один или два линк-поинтера, смотри польный ман, линуксовский ман — это жалкий огзызок), но на фоне сетевых затыков всем этим можно пренебречь, в том числе и static vs. malloc. т.ч. не занимайся premature optimization.

вот тебе ещё пару примеров их использования.

а чему там тормозить? это чистые макросы

ок. думаю на 50к элементах даже поиск можно тупым FOREACH делать :)

Возьми protobuf

Возьми protobuf

Я бы с удовольствием, но заказчик не хочет Си++. Он хочет pure C.

spgt

А клиенты какие? Браузеры? Если да, то примеров есть. Например, если хочется асинхронности, то libevent и примеры httpd к нему. Если хочется отдельных потоков на запрос(или соединение, если keep-alive) - http://tinyhttpd.sourceforge.net/, например. Ну или Стивенс, там тоже есть. Опять же, если это веб, вот такими «пакетами» обычно обмениваются в виде JSON

Ну или Стивенс, там тоже есть.

Спасибо, почитаю. Я привык к бумажным книгам - Стивенса купил лет 8 назад, но почти не изучал.

Вы какой-то потребительский софт разрабатываете? Или что-то узкоспециальное, с возможностью контроля инсталляций?

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

я делаю так (выделение пакетов из потока байтов):

1) заводится буфер с размером равным размеру самого большого пакета

2) пишется функция, которая получает на вход указатель на начало пакета, количество полученных байтов и возвращает размер пакета. Если количество полученных байт недостаточно для определения размера, возвращается максимальный размер типа (MAX_INT или что-то в этом роде, в общем чтобы больше размера буфера)

3) делаем в цикле

ret = recv (socket, buf + pos, bufsize - pos, 0);

pos += ret;

while(pos > 0) //цикл потому что одним куском может прийти несколько пакетов
{
msgsize = getpacketsize(buf, pos);

if (msgsize > pos)
  break;

//здесь обрабатываем полученный пакет
...

pos -= msgsize;

//сдвигаем оставшиеся данные к началу буфера
memmove(buf, buf + msgsize, pos);//тупо, можно замутить кольцевой буфер
}

//сдвигаем оставшиеся данные к началу буфера

ок, спасибо за поддержку. Видимо, zero-copy всё-таки не получится. Буду делать как и ты.

Или что-то узкоспециальное, с возможностью контроля инсталляций?

Узкоспециализированное.

Во-вторых реально много пользователей сидят за прокси

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

я тут в процессе задумался, как избавиться от memmove(). Можно убирая обработанный пакет передвигать указатель buf, но возможна такая ситуация - приходит небольшой пакет, вслед за ним пакет максимального размера, и писать его некуда, упираемся в конец буфера. Тогда надо либо увеличивать на лету буфер, либо копировать хвост пакета в начало буфера, и потом склеивать пакет из двух кусков идущих в обратном порядке, что потребует копирования большего числа байт, чем в случае с memmove()

Прохождение HTTP через прокси - это, скорее, такой бонус. Пойнт был не в этом. Использование HTTP (точнее, готовых компонентов для него) сильно упрощает сетевое программирование. Не нужно заморачиваться всякой низкоуровневой и нудной ерундой типа «как узнать что клиент отвалился», «что делать когда клиент передал не весь пакет и завис», и т.п.

В более-менее современных веб-серверах или библиотеках для их написания все это (как и прочие c10k проблемы) давно решено. libevent, 30 строк кода на сишечке из примера - и мы уже получаем полное сообщение, его размер, отправителя, опционально что-нибудь еще в куке.

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

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

А почему по пакетам не читать?

Читаем 5 байт, узнаем DataSize, читаем DataSize байт.

Есть пакет, можно обрабатывать и получать следующий.

// //memmove(buf, buf + msgsize, pos);//тупо, можно замутить кольцевой буфер

//сдвигаем оставшиеся данные к началу буфера

ок, спасибо за поддержку. Видимо, zero-copy всё-таки не получится. Буду делать как и ты.

Замути лучше кольцевой буфер.

Использование HTTP (точнее, готовых компонентов для него) сильно упрощает сетевое программирование.

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

заведи буфер размером 2 * PACKET_SIZE_MAX :)