Теоретическая задачка нахождения потолка производительности сети.

протокол TCP сам за это отвечает

Да, по идее TCP не допустит потери данных. Так что пропускная способность клиента определяется пропускной способностью 3G.

Может он и отвечает, но если беспрерывно писать в сокет, данные начинают теряться. я так понимаю это из-за большой разницы в ширине канала. 1Gbit/s — internet — 7/1/0.5 mbit/s и в современном алгоритме контроля скорости cubic.

В этом случае он незашчто не может ответить. Во всяком случае так получается.

Извините, но вы сейчас перепутали переливание яги из ведра в бутылку с IT технологиями. Пожалуйста включите свой мозг, а так же прочтите RFC 793

если непрерывно писать в сокет, то рано или поздно send вернет -1 с ошибкой переполнения буфера. Соответственно, надо притормозить, подождать пока буфер рассосётся, и продолжить снова

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

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

Harald

подождать пока буфер рассосётся, и продолжить снова

Где про это можно почитать?

man send

man send и далее

Jetty

Пожалуйста включите свой мозг, а так же прочтите RFC 793

Еcли найдешь в этом документе от 1981 года упоминание реализации CUBIC TCP получишь пирожок.

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

Но это вроде как под виндой только, точно не уверен

ббрррррр Я пишу так:

w = write(fd, buf, len)

Harald

..., в результате неблокирующий сокет не будет возвращаться из send, пока не получит ACK от удаленной стороны.

хрень. будет нормально работать только в локальной сети с одним свитчем. т.к. RTT(время пакета в пути) очень большой, хотя скорость 3G тоже приличная.

Могу привести аналогичный пример: Спутниковый интернет.

а что ты потом с w делаешь?

зато не переполнится :) выше скорости клиента не будет пихать данные

Harald

а что ты потом с w делаешь?

а что ты потом с w делаешь?Смотрим сколько незаписалось и отправляем потом. Но такая фигня бывает редко. Обычно если что-то возвратилось значит уже где-то коллапс и кто-то отбросил твои пакеты.

Сейчас введен вес, который растчитывается из времени входа и возврата из write(..) . Но что входит во время работы write, мне не совсем понятно.

Harald

зато не переполнится :) выше скорости клиента не будет пихать данные

При большой задержке если не пихать данные заранее, максимальную производительность канала клиента не выбрать. Она будет где-то 10%.

возврат -1 тоже надо обрабатывать, типа вот так:

	ret = send( s, buf, *ppos, MSG_NOSIGNAL);

	if (ret > 0)
		{
		if (ret < *ppos)
			memmove( buf, buf + ret, *ppos - ret);
		*ppos -= ret;
		}
		
	if (ret < 0)
		{
#ifdef WIN32
		ret = WSAGetLastError();
		if (! (ret == WSAEWOULDBLOCK || ret == WSAENOBUFS))
#else
		ret = errno;
		if (! (ret == EAGAIN || ret == ENOBUFS || ret == EINTR))
#endif
			return ERRSOCK;
		}
	if (ret == 0)
		return ERRSERV;

данные начинают теряться

На сколько я знаю, если теряются пакеты (а не данные), то отправитель уменьшает скорость до тех пор пока они теряться перестанут. Так что всё автоматом дойдёт до той скорости, на которую способен получатель. Кстати в icmp (v4) есть такой пакет, получатель просит уменьшить скорость отправителя. Может это тоже сюда, но я не уверен. Там ещё какая-то фишка есть с размерами буферов, но я деталей не знаю. Про cubic ничего не знаю, если что.

nanoolinux

Про cubic ничего не знаю, если что.

CUBIC оптимизирован под толстые каналы. Он сразу начитает передавать много пакетов.(если в двух словах)

Harald

ret == EAGAIN || ret == ENOBUFS || ret == EINTR

Не вижу обработки этих ошибок.

обработка заключается в повторном вызове send с теми же параметрами в следующий раз :)

Если это весь код отправки,то Вы не проверяете значение возвращаемые в переменную w.

ты пытаешся лезть в тонкости tcp непонимаю основ работы с сетью и tcp
tcp обеспечивает соединение двух сторон - если с ним правильно работатть - работать с сокетами - и обрабатывать ошибки их - то НИКАКИХ потерь данных небудет
реализации внутренних алгоритмов могут быть различными - но это тонкости
более верхняя его часть - всегда будет обеспечивать сохранность канала - просто в разных случаях это будет более эффективно - в других менее

читай про обработку ошибок при работе с сокетами read-write и так далее

а насчет того - как определить пропускную способность канала - то ничего сильно лучше того алгоритма что использует tcp и нету