Построить быстрый эхо сервер при приёме и передаче различных по объёму данных от 10 байт до 100 кбайт

Как построить быстрый эхо сервер.при приёме и передаче различных по объёму данных от 10 байт до 100 кбайт.

0

Сообщение от hvt1962 Как построить быстрый эхо сервер

взять и построить. как минимум определиться с тем что это за сервер TCP/UDP/XXX??? если нужен вариант по существу: создать сокет, сделать бинд, поставить на прослушивание, селектом проверять наличие запроса на подключение, делать ассепт, селектом проверять наличие входящих данных, принимать их через рецв, отправлять через сенд

0

Да это мне понятно, то что вы написали есть в любом примере по построению клиент- сервер, как чистым сервером (то, что Вы описали), так и через различные библиотеки. Самый простой вопрос к Вам как вы определите окончание приема данных, если работать через буфер?

0

Сообщение от hvt1962 как вы определите окончание приема данных, если работать через буфер?

о каком окончании приема идет речь если вы делаете эхо? пришли 10 байт - отправили 10 байт. пришили 100 кбайт - отправили 100 кбайт. все с колес. никаких буферов. это же эхо. или у вас не просто эхо? тогда конечно нужно знать протокол. из него будет понятно где конец

0

Ну тогда какой размер для recv буфера мне выделять 100 кбайт?

Добавлено через 1 минуту
Вы не путайте, с прокси сервером, пакет пришел перенаправил и все.

0

Сообщение от hvt1962 Ну тогда какой размер для recv буфера мне выделять 100 кбайт?

любой. если это действительно эхо. хоть 1 байт. пришел байт "а" эхо послало в ответ "а".

Сообщение от hvt1962 Вы не путайте, с прокси сервером, пакет пришел перенаправил и все.

а тут не все)?

0

я говорю утрировано про прокси. Просто в протоколе TCP реализована разновидность алгоритма квитирования с использованием окна. Поэтому, я думаю, что в момент квитирования, между сервером и клиентом возможно заполнения моего буфера, но тогда встает вопрос, как узнать размер окна.

Добавлено через 3 минуты
как вы перешлете 1 байт при передаче 10 байт по симплексному каналу.

Добавлено через 19 минут
До еще забыл сказать, что максимальный размер сегмента TCP пакета, может быть 64536 байт.) при IPv4.

0

Сообщение от hvt1962 разновидность алгоритма квитирования с использованием окна

Сообщение от hvt1962 как вы перешлете 1 байт при передаче 10 байт по симплексному каналу

Сообщение от hvt1962 максимальный размер сегмента TCP пакета, может быть 64536 байт

))) какое все это имеет значение? для вас TCP - это поток байт. прыгнуть выше - значит стать на один уровень с ОС. если знаете как - раскажите. размер окна может быть (точно я этого не знаю) лежит в переменных доступных через getsockopt SO_SNDBUF/SO_RCVBUF

1

Сообщение от vxg прыгнуть выше - значит стать на один уровень с ОС.

Ха-ха-ха, смешно. Компонент Indi юзайте. Он, между прочим, и на вижил студия работает.

0

Сообщение от SmittWesson Компонент Indi юзайте

и? он работает не через WinAPI send/recv?

0

Я, когда задавал этот вопрос, подразумевал, что будет предложен эхо сервер на IOCP и все сервера с ним связанные под другие ОС. В связи с чем, изменяю свой вопрос организация эхо сервера на IOCP(ближе к ОС).

Добавлено через 22 минуты
т.е. организация такая, как я себе представляю. есть поток Accept,который передает сокет в поток Read который считывает данные до GetQueuedCompletionStatus() и он передает данные в поток Write. Тогда возникает вопрос, нужен mybufer или достаточно readbufer(для случая получения пакета и отправить в очередь на отправку в потоке Write) для передачи данных и опять, как определить оптимальный размер буфера readbufer.

Добавлено через 1 час 15 минут
В описании TCP протокола сказано "Размер дейтаграммы в байтах с учетом заголовка и данных. Размер поля позволяет использовать дейтаграммы длиной до 65535 байтов, хотя такой размер нежелателен для многих сетей и хостов. Все хосты должны быть готовы к приему дейтаграмм размером до 576 байтов, независимо от того как они доставляются – целиком или фрагментами. Рекомендуется передавать дейтаграммы, размер которых превышает 576 байтов только в тех случаях, когда адресат готов принять такие дейтаграммы." Можно ли считать оптимальным буфером размер в 576 байт.

0

Сообщение от hvt1962 В описании TCP протокола сказано "Размер дейтаграммы

TCP + дейтаграммы ?

Вот правильно ведь vxg написал выше: TCP - это поток байт.
Никаких там пакетов, дейтаграмм, заголовков и т.п. вы не увидите,
как не пытайтесь.

0

Насчёт дейтограммы -это перевод. А как правильно вы считаете называть окно,сегмент.. . просто у нас принято если дейтограмма то это Udp.

0

hvt1962, Вы немного не в ту степь ушли. Сегменты, дейтаграммы...
TCP можно рассматривать как некий сервис, который предоставляет
следующие интерфейсы:

- connect (установка соединения);
- shutdown (закрытие соединения);
- send (отправка данных);
- recv (прием данных)
ну еще listen и accept на серверной стороне.

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

0

А я туда и не лез, я просто задал вопрос про построение эхо сервера(т.к. он просто сервер который принимает и передает без всяких дальнейших наворотов). А после конкретизировал вопрос о размере recvбуфера(SO_SNDBUF/SO_RCVBUF это управление размером дейтограмм) и необходимости использования myбуфера( если данные которые передаются превышают recvбуфер).

Добавлено через 19 минут
Я не правильно выразился SO_SNDBUF/SO_RCVBUF - это не управление размером дейтограмм, а управление приемным/передающим буфером. В некоторых статьях по оптимизации буферов рекомендуют устанавливать приемный буфер 65535 байт, а передающий 576 байт или меньше(тогда начинает работать алгоритм Нейгла).

Добавлено через 28 минут
Но что делать, когда размер сообщения меньше 576 байт ( вроде задержка Нейгла в windows 20 mсек).

0

IMHO, при постановке задачи "как построить быстрый эхо сервер, при приёме и передаче
различных по объёму данных от 10 байт до 100 кбайт" все эти заморочки с алгоритмом
Нейгла, высчитыванием оптимального размера буфера приема и отправки и т.п. не нужны.
Существующие реализации TCP настолько совершенны, что никакой разницы и каких-либо
отклонений от нормы вы при этом тюнинге не почувствуете (если вообще не сделаете хуже).

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

Простой асинхронный сервер с пулом потоков, написанный "на коленке" с использованием, к
примеру, Boost.Asio, уже будет держать приличную нагрузку и не требовать никакой "подгонки".
Уверяю, производительности этой системы для поставленной задачи хватит более чем.

Что касается конкретно реализации эхо-сервера на TCP - мне кажется, задача поставлена
не совсем точно. TCP сам по себе - это поток байт и без знания того, что находится в
этих байтах, вы не можете знать, где кончается один логический кусок данных и
начинается следующий (если только не брать в расчет закрытие или разрыв соединения).
Это в ICMP, например, размер пинг-пакета заранее известен, а в TCP такого нет.

Так что здесь, видимо, читать recv нужно до тех пор, пока не придет 0 (это будет означать
закрытие соединения на том конце) и только после этого отправить данные обратно.

0

Я про нагрузку на сервер не чего не говорил. Меня интересует канал связи.Может перед приёмов данных сделать ping клиента(icmp), а потом на основании этих данных использовать буфер.

0

Сообщение от hvt1962 я просто задал вопрос

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

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

1

vxg, спасибо большое. Теперь хоть направление движения определилось. Буду разбираться.

Добавлено через 37 минут
Для тех кто интересуется, для чего я задал этот вопрос есть хорошая статья http://habrahabr.ru/company/croc/blog/214693/

0

Там вообще ничего не говорится о среде передачи данных. MTU для того же Ethernet 1500, что собственно больше 576 и меньше 65535. Если произойдет какая та блокировка в положение, то на сокете может оказаться значение больше MTU.

0