Вот назрел такой вопрос пишу сервер, кот. слушает по определённому порту клиента.
Работа в режиме запрос-ответ.
Иногда возникают ситуации, когда приходит запрос и готовится на него ответ, за это время клиент может ещё слать мне запросы.... Так вот после ответа приходят ко мне запросы, а вернее сказать запрос который есть склееные запросы к серверу за время пока отвечал сервер... а это не есть хорошо
Можно ли как-то это пофиксить? Чтоб они приходили в порядке очереди?

P.s.: многопоточность не подходит.
P.s.1: MS VC++ ; MFC; в основе — берклиевский классический сервер.

Здравствуйте, -Cheese-, Вы писали:

C>Вот назрел такой вопрос пишу сервер, кот. слушает по определённому порту клиента.
C>Работа в режиме запрос-ответ.
C>Иногда возникают ситуации, когда приходит запрос и готовится на него ответ, за это время клиент может ещё слать мне запросы.... Так вот после ответа приходят ко мне запросы, а вернее сказать запрос который есть склееные запросы к серверу за время пока отвечал сервер... а это не есть хорошо
C>Можно ли как-то это пофиксить? Чтоб они приходили в порядке очереди?

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

C>P.s.: многопоточность не подходит.
C>P.s.1: MS VC++ ; MFC; в основе — берклиевский классический сервер.

Здравствуйте, CrystaX, Вы писали:

CX>Здравствуйте, -Cheese-, Вы писали:

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

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

C>>Можно ли как-то это пофиксить? Чтоб они приходили в порядке очереди?

CX>TCP? Тогда маркер в конце каждого сообщения или размер сообщения в самом начале.
+1

Именно. Причем нужно будет позаботиться о буфере куда данные из канала поступают и там парсятся. Те данные, которые успешно распарсены из буфера изымаются. Остальны остаются ждать продолжения.

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

Лично я использую размер сообщения в его залоговке.

CX>Если UDP, то проблемы нет — приходящие дейтаграммы не склеиваются в одну. Правда, есть риск их потери.

C>>P.s.: многопоточность не подходит.
C>>P.s.1: MS VC++ ; MFC; в основе — берклиевский классический сервер.

Здравствуйте, eao197, Вы писали:

E>Если сообщения имеют регулярную текстовую структуру (например, XML), то можно обойтись без меток или размера -- сама структура сообщения позволит выделить сообщение целиком. Но это может быть не эффективно на больших сообщениях.

Пример: HTTP. Есть заголовок Content-Length, в котором указывается длина body.

E>Лично я использую размер сообщения в его залоговке.

Да, это самое эффективное, если протокол разрабатываешь сам.

Здравствуйте, eao197, Вы писали:

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

т.е. мне нужно следующее начинать с 2+503 байта?
а это все данные там....?
короче возюкаться нужно... а так всё прекрасно начиналось.... (до большой частоты обращений к серверу )

Здравствуйте, -Cheese-, Вы писали:

C>Здравствуйте, eao197, Вы писали:

E>>Лично я использую размер сообщения в его залоговке.
C>ага
C>мне, например, приходит сообщение в заголовке указано 503 байта
C>а протокол говорит, что ты мол получил, 1013 байт

C>т.е. мне нужно следующее начинать с 2+503 байта?
C>а это все данные там....?
C>короче возюкаться нужно... а так всё прекрасно начиналось.... (до большой частоты обращений к серверу )

Если тебе некоторый (как правило, небольшой) процент потерь некритичен, используй UDP.

Здравствуйте, CrystaX, Вы писали:

CX>Если тебе некоторый (как правило, небольшой) процент потерь некритичен, используй UDP.

ещё как критичен.... по шеям можно получить

Здравствуйте, -Cheese-, Вы писали:

C>Здравствуйте, CrystaX, Вы писали:

CX>>Если тебе некоторый (как правило, небольшой) процент потерь некритичен, используй UDP.

C>ещё как критичен.... по шеям можно получить

Ну тогда только с помощью буффера. TCP не гарантирует, что ты получишь весь пакет за один раз или за один раз только один пакет. Даже более того — возможна ситуация, когда при чтении из сокета ты получаешь меньшее количество байт, чем запрашивал, и это ничего не значит. При следующем чтении ты запросто можешь прочитать еще кусок (равный или меньший запрошенному количеству). Конец соединения происходит только при возврате 0 байт.
TCP — потоковый протокол. Разбить его на смысловые фрагменты — уже пользовательская (твоя) задача. Вообще говоря, ничего страшного здесь нет. Сам сейчас занимаюсь подобными вещами.

Здравствуйте, CrystaX, Вы писали:

CX>Здравствуйте, eao197, Вы писали:

E>>Если сообщения имеют регулярную текстовую структуру (например, XML), то можно обойтись без меток или размера -- сама структура сообщения позволит выделить сообщение целиком. Но это может быть не эффективно на больших сообщениях.

CX>Пример: HTTP. Есть заголовок Content-Length, в котором указывается длина body.

Я имел в виду чуть-чуть другое. Например, когда сообщения имеют вид:

<message>
    <action>
        <name>Do Something</name>
        <param_count>2</param_count>
        <param ordinal="1" value="With this..." />
        <param ordinal="2" value="...and this!" />
    </action>
</message>

Если поступают большие блоки данных, в которых могут быть множество подобных небольших данных, то их может быть удобно разбирать SAX-парсером. Выбрасывая при этом успешно пропарсенные сообщения и останавливаясь на первом сообщении, которое не поместилось в буфер полностью.

Здравствуйте, -Cheese-, Вы писали:

C>Здравствуйте, eao197, Вы писали:

E>>Лично я использую размер сообщения в его залоговке.
C>ага
C>мне, например, приходит сообщение в заголовке указано 503 байта
C>а протокол говорит, что ты мол получил, 1013 байт

C>т.е. мне нужно следующее начинать с 2+503 байта?
C>а это все данные там....?
C>короче возюкаться нужно... а так всё прекрасно начиналось.... (до большой частоты обращений к серверу )

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

Вот, например, как у меня идет разбор входящего трафика:

so_4::ret_code_t
client_connection_t::read()
{
    // Пытаемся прочитать очередную порцию данных.
    unsigned int bytes_to_read = query_read_buf_size();
    auto_ptr_3::vect_ptr_t< char > buf(
        new char[ bytes_to_read ], bytes_to_read );
    unsigned int bytes_read;

    so_4::ret_code_t rc;
    /* m_phys_channel_ptr -- это объект, который физически работает с сокетом. */
    rc = m_phys_channel_ptr->read(
        buf.query(), bytes_to_read, bytes_read );
    if( rc == success )
    {
        // Чтение прошло без ошибок.
        size_t size;
        /* В моем случае данные могут быть заархивированны, метод transform_incoming распаковывает их и помещает в атрибут m_ibuf. */
        rc = transform_incoming( buf.query(), bytes_read, size );

        // Если что-то трансформировали, то нужно
        // поместить это в промежуточный буфер и
        // попробовать разобрать.
        if( rc == success && size )
            /* parse_ibuf -- это виртуальный метод, который переопределяется для разных типов соединений. */
            rc = parse_ibuf();
    }

    return rc;
}

/* Вот в этом производном классе разбираются данные, в которых есть специальный заголовок с длиной сообщения. */
so_4::ret_code_t
sop_client_connection_t::parse_ibuf()
{
    /* Идем в начало буфера чтобы начать его новый просмотр. */
    m_ibuf.set_pos( 0 );
    while( so_4::sop::package_header_t::e_image_size <= m_ibuf.size() )
    {
        // Считываем заголовок пакета и проверяем его.
        so_4::sop::package_header_t header;
        m_ibuf >> header;
        if( header.is_valid() )
        {
            // Заголовок корректен. Обрабатываем тело пакета.
            unsigned int body_size = header.size();
            // Если все тело пакета находится в буфере, то
            // изымаем его и отсылаем на обработку.
            if( so_4::sop::package_header_t::e_image_size +
                body_size <= m_ibuf.size() )
            {
                /* Сюда попадаем только, если в буфере сообщение находится целиком. */
                so_4::rt::msg_auto_ptr_t< msg_sop_package >
                    msg( new msg_sop_package() );
                msg->m_channel = m_comm_channel;
                msg->m_package.insert( 0, m_ibuf,
                    m_ibuf.pos(), body_size );
                // Заблокирован ли канал?
                bool is_blocked = ( msg->m_is_blocked =
                    in_package_processed( body_size ) );
                msg.send( communicator_agent_name(),
                    "msg_sop_package" );

                // Обработанные данные из буфера нужно изъять.
                /* Вот так данные из промежуточного буфера удаляются. После этого указатель перемещается в начало буфера. */
                m_ibuf.erase( 0,
                    so_4::sop::package_header_t::e_image_size +
                    body_size );

                // Если канал оказался заблокированным, то разбор
                // буфера нужно прекратить.
                if( is_blocked )
                    break;
            }
            else
                // В буфере недостаточно данных.
                // Просмотр буфера можно прекратить.
                break;
        }
        else
        {
            // Обнаружен некорректный заголовок.
            return so_4_make_rc( invalid_package_header,
                "Invalid SOP package header" );
        }
    }

    // Если после просмотра в буфере оказалось слишком
    // много данных, то это ошибка.
    if( m_ibuf.size() > m_ibuf_max_size )
    {
        return so_4_make_rc( ibuf_too_large,
            "Input buffer is too large" );
    }

    return so_4::ret_code_t();
}

Так что, если нет желания с такими низкоуровневыми особенностями разбираться, то возьми какую-нибудь готовую библиотеку. Тот же ACE, например. В нем и чтение/запись реализованы. И специальный класс MessageBlock. И специальный класс для перекодировок значений в BigEndian/LittleEndian.

Либо вообще откажись от собственного низкоуровневого протокола в пользу чего-нибудь готового. Например, CORBA, Ice, SOAP, XML-RPC. Или даже собственный протокол поверх HTTP: во-первых, ты получишь готовый транспортный уровень, во-вторых, request/response протоколы на основе HTTP (да и CORBA) могут хорошо маштабироваться (с балансировкой нагрузки на несколько web-серверов) + отказоустойчивость в этом случае есть.

Здравствуйте, eao197, Вы писали:

E>Здравствуйте, CrystaX, Вы писали:

CX>>Здравствуйте, -Cheese-, Вы писали:

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

E>Это вообще фундаментальная особенность TCP-трафика: пакеты, которые на отправляющей стороне отсылаются отдельно, поступать могут на принимающую сторону либо склеенными, либо наоборот -- разделенными на более мелкие части.

C>>>Можно ли как-то это пофиксить? Чтоб они приходили в порядке очереди?

CX>>TCP? Тогда маркер в конце каждого сообщения или размер сообщения в самом начале.
E>+1

E>Именно. Причем нужно будет позаботиться о буфере куда данные из канала поступают и там парсятся. Те данные, которые успешно распарсены из буфера изымаются. Остальны остаются ждать продолжения.

E>Если сообщения имеют регулярную текстовую структуру (например, XML), то можно обойтись без меток или размера -- сама структура сообщения позволит выделить сообщение целиком. Но это может быть не эффективно на больших сообщениях.

E>Лично я использую размер сообщения в его залоговке.

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

Здравствуйте, eao197, Вы писали:

E>Здравствуйте, CrystaX, Вы писали:

CX>>Здравствуйте, eao197, Вы писали:

E>>>Если сообщения имеют регулярную текстовую структуру (например, XML), то можно обойтись без меток или размера -- сама структура сообщения позволит выделить сообщение целиком. Но это может быть не эффективно на больших сообщениях.

CX>>Пример: HTTP. Есть заголовок Content-Length, в котором указывается длина body.

E>Я имел в виду чуть-чуть другое. Например, когда сообщения имеют вид:
E>

E><message>
E>    <action>
E>        <name>Do Something</name>
E>        <param_count>2</param_count>
E>        <param ordinal="1" value="With this..." />
E>        <param ordinal="2" value="...and this!" />
E>    </action>
E></message>
E>

E>Если поступают большие блоки данных, в которых могут быть множество подобных небольших данных, то их может быть удобно разбирать SAX-парсером. Выбрасывая при этом успешно пропарсенные сообщения и останавливаясь на первом сообщении, которое не поместилось в буфер полностью.

Да, я понял. Но в данном случае это непринципиально. Ровно так же на этом месте может быть множество HTTP сообщений.

Здравствуйте, c0unt, Вы писали:

E>>Лично я использую размер сообщения в его залоговке.

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

Это неактуально в случае TCP.

Здравствуйте, eao197, Вы писали:

E>Либо вообще откажись от собственного низкоуровневого протокола в пользу чего-нибудь готового. Например, CORBA, Ice, SOAP, XML-RPC. Или даже собственный протокол поверх HTTP: во-первых, ты получишь готовый транспортный уровень, во-вторых, request/response протоколы на основе HTTP (да и CORBA) могут хорошо маштабироваться (с балансировкой нагрузки на несколько web-серверов) + отказоустойчивость в этом случае есть.

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

Здравствуйте, -Cheese-, Вы писали:

C>Здравствуйте, eao197, Вы писали:

E>>Либо вообще откажись от собственного низкоуровневого протокола в пользу чего-нибудь готового. Например, CORBA, Ice, SOAP, XML-RPC. Или даже собственный протокол поверх HTTP: во-первых, ты получишь готовый транспортный уровень, во-вторых, request/response протоколы на основе HTTP (да и CORBA) могут хорошо маштабироваться (с балансировкой нагрузки на несколько web-серверов) + отказоустойчивость в этом случае есть.

C>не получится... клиент как бы написан не мною и это есть приложение, кот. общается со многими серверами, в том числе и моим по определённому протоколу.

Тогда могу посоветовать посмотреть-таки в сторону ACE и почитать книгу: C++ Network Programming vol1: Mastering Complexity with ACE and Patterns (она была в eMule). Даже если ты ACE и не будешь использовать, то хотя бы для общего развития она будет полезна.

Здравствуйте, CrystaX, Вы писали:

CX>Ну тогда только с помощью буффера. TCP не гарантирует, что ты получишь весь пакет за один раз или за один раз только один пакет. Даже более того — возможна ситуация, когда при чтении из сокета ты получаешь меньшее количество байт, чем запрашивал, и это ничего не значит. При следующем чтении ты запросто можешь прочитать еще кусок (равный или меньший запрошенному количеству). Конец соединения происходит только при возврате 0 байт.
CX>TCP — потоковый протокол. Разбить его на смысловые фрагменты — уже пользовательская (твоя) задача. Вообще говоря, ничего страшного здесь нет. Сам сейчас занимаюсь подобными вещами.

если не сложно.. можно ссылочку (ну или вкратце обьяснить) на то, как склеиваются сообщения (по какому принципу) . Что я их правильно распарсил.

Спасибо!

Здравствуйте, -Cheese-, Вы писали:

C>если не сложно.. можно ссылочку (ну или вкратце обьяснить) на то, как склеиваются сообщения (по какому принципу) . Что я их правильно распарсил.

А принципа никакого нет. Как придут, так и будут склеены.

Вот у меня сейчас сделано так:
Есть буфер необработанных сообщений. Это просто plain text. Я натравливаю на этот буфер парсер. Парсер возвращает три состояния.
1. ОК, сообщение прочитано. В этом случае оно удаляется из буффера (его длина известна, т.к. оно уже распарсено) и производится попытка парсинга следующего сообщения.
2. В буфере лежит корректное сообщение, но не полное (буфер закончился). В таком случае парсинг откладывается на потом, когда придут дополнительные данные. С буфером никаких действий не предпринимается.
3. Парсер выдает ошибку (некорректное сообщение). Обрабатываем ошибочную ситуацию.

В отдельном потоке при этом крутится цикл приема сообщений и помещения их в буфер.

Это одна из возможных схем реализации. Какую именно выбрать тебе — нужно решать на основании твоей задачи.

Здравствуйте, CrystaX, Вы писали:

CX>А принципа никакого нет. Как придут, так и будут склеены.

CX>Вот у меня сейчас сделано так:
CX>Есть буфер необработанных сообщений. Это просто plain text. Я натравливаю на этот буфер парсер. Парсер возвращает три состояния.
CX>1. ОК, сообщение прочитано. В этом случае оно удаляется из буффера (его длина известна, т.к. оно уже распарсено) и производится попытка парсинга следующего сообщения.
CX>2. В буфере лежит корректное сообщение, но не полное (буфер закончился). В таком случае парсинг откладывается на потом, когда придут дополнительные данные. С буфером никаких действий не предпринимается.
CX>3. Парсер выдает ошибку (некорректное сообщение). Обрабатываем ошибочную ситуацию.

CX>В отдельном потоке при этом крутится цикл приема сообщений и помещения их в буфер.

CX>Это одна из возможных схем реализации. Какую именно выбрать тебе — нужно решать на основании твоей задачи.

не совсем понял...
В основном мне приходят склееные >=2 сообщения..
вот к примеру ко мне приходят сообщения вида
(2 байта для размера сообщения) +
іmessage1
іmessage2
так вот что это за символ (
і)? Всегда ли он отделяет сообщение одно от другого?
как мне их отделить?

Здравствуйте, -Cheese-, Вы писали:

C>не совсем понял...
C>В основном мне приходят склееные >=2 сообщения..
C>вот к примеру ко мне приходят сообщения вида
C>(2 байта для размера сообщения) +
іmessage1
іmessage2
C>так вот что это за символ (
і)? Всегда ли он отделяет сообщение одно от другого?
C>как мне их отделить?

Это какие-то части сообщений тоже. TCP не добавляет никаких маркеров. Это поток в чистом виде и ничего более. Ты уверен, что там именно 2, а не 4 байта, обозначающих размер? Кроме того, какое представление целочисленных величин используется (какой byte-order)?

Здравствуйте, CrystaX, Вы писали:

CX>Это какие-то части сообщений тоже. TCP не добавляет никаких маркеров. Это поток в чистом виде и ничего более. Ты уверен, что там именно 2, а не 4 байта, обозначающих размер?
когда не слеиваются, то точно 2 байта

CX>Кроме того, какое представление целочисленных величин используется (какой byte-order)?
Чего?