Как работает сетевой сокет при записи/чтении?

Question

[Alexey Polyakov]

Добрый день,

Объясните простыми словами, как работает связка сокет-стрим при чтении записи? В частности, мы создаем сокет, создаем стрим, пишем туда данные из буфера, на другом конце в ожидании данных while(true), потом, обычно в примерах, отправили и ждем ответ, в php например $out = socket_read и т.д., а если данных нет или они с задержкой, или сначала там отправили первую часть, а вторая часть через пять секунд отправлена, а здесь уже socket_read == false. Как это все регулируется, чтобы отойти от схемы отправил-сразу получил, закрыл и забыл? Как управлять кто ждет, сколько ждет, чего ждет и т.д.?

Comments

[Alexey Polyakov]

Вот, например, отправляю данные в сокет десять раз,
$_data = $this->PrepareData($_d);

$this->SocketConnect();
$this->Send($_data);
$this->Send($_data);
$this->Send($_data);
$this->Send($_data);
$this->Send($_data);
$this->Send($_data);
$this->Send($_data);
$this->Send($_data);
$this->Send($_data);
$this->Send($_data);
$respond = $this->Receive();
print_r($respond);
$this->Close();

отключил сервер на эхо, в консоли сервера получаю только один вывод отправленных данных, где остальные девять? На каком этапе сервер перестает их принимать? Я полагаю что чтобы туда не сбросили, он должен все ловить пока команда не поступит, что "все, больше ничего нет, делай там что нужно со всем что получил". Или socket_write отправляет какие-то "завершающие симоволы" в пакете данных, что срабатывает stream.DataAvailable (это уже на NET) и отключает stream.Read?

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

Answer 1

[Александр Юдаков]

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

На этом задачи сокета заканчиваются. Т.е. ваш вопрос не имеет отношения к сокетам.

Вопрос о том, сколько надо читать (и ждать), решается не на транспортном, а на прикладном уровне. Т.е. перед вами фактически стоит задача: разработать протокол прикладного уровня - придумать правила, чего и сколько должна отправлять и ждать каждая из сторон сетевого взаимодействия.

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

Тогда работа получателя в этом случае проста:
1) читаем из сокета 4 байта - длину сообщения;
2) читаем из сокета еще столько байт, сколько указано в длине сообщения.

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

Upd.
NetworkStream.DataAvailable всего лишь показывает нам, что данные уже поступили и их можно забрать с помощью Read, однако ничего не говорит о том, сколько еще данных ожидается и уж тем более НЕ сигнализирует о том, что другая сторона закончила передачу данных:

"Use the DataAvailable property to determine if data is ready to be read. If DataAvailable is true, a call to Read returns immediately."
https://docs.microsoft.com/en-us/dotnet/api/system...

Comments

[Alexey Polyakov]

Немного подразобрался и провел несколько экспериментов.
1) DataAvailable работает в цикле и касается скорее считывания данных в буфер, чем контроля нетворкстрима в целом. То есть в стриме есть данные, буфер меньше, считываем в цикле по кусочкам.
2) Возможно, если за зти миллисекунды что-то дополнительно придет, то количество данных в стриме увеличится (в частности, я делал цикл из 100 записей в стрим и все они считывались циклом, при этом если посередине цикла клиента поставить задержку, то цикл DataAvilable закроется. Сколько миллисекунд эта задержка может быть - не подбирал, т.к. смысла нет.
3) Так как в php после создания сокета есть подключение, но нет отключения (есть только закрытие сокета), решил проверить скорость работы цикла подключений с генерацией строки в каждом цикле - сто подключений, каждое со строкой из ста частей - не знаю много ли это, но наверное какие-то стандартные операции по сериализации закрывает. Короче говоря, за секунду пролетели все эти сто подключений с открытием в net новых потоков, обработкой, в консоли смешались все отладочные выводы, но отработало практически мгновенно, поэтому можно не заморачиваться вообще темой "какую часть из организации нового подключения в php вынести на несколько отправок в стрим, чтобы типа быстрее и эффективнее работало". Никакую. Можно создавать стрим, делать подключение, генерить данные (лучше заранее их генерить), подключаться, направлять одним куском, без задержек между отправками, получать ответ и отключаться, и все это сотни раз в секунду нормально работает на стандартном сервачке. Если же прям очень сильно хочется дописывать в стрим, каждые пару секунд, то DataAvilable не подойдет, из других методов есть ReadTimeOut, но он блокирует время на считывания и как бы несет другой смысл, можно также приостанавливать поток на сколько-то миллисекунд и уменьшить буфер - но это как тихоходную тележку поставить, чтобы все на нее успевали запрыгивать - не вариант. То есть остается только в цикле уже выискивать в стриме управляющие куски.

Спасибо всем за участие.