TCP Socket Что такое «поток событий», когда два узла разговаривают

Question

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

Я создаю клиентское приложение TCP <-> для сервера.

Помогите мне понять, каков правильный протокол событий (должен быть) для моего клиента и сервера для разговора.

Что я ожидаю, что смогу сделать:

1. Сервер слушает.
2. Клиент подключается к серверу.
3. Клиент отправляет строку на сервер.
4. Сервер получает данные

5. Сервер отвечает обратно (я вручную отправляю "<ok>" string)

6. Здесь и сейчас я ожидаю, что мой клиент будет охлаждаться, зависать и ничего не делать, пока не сработает send method для отправки новых данных на сервер.

7. Затем я ожидаю, что сервер получит указанные данные, и повторите шаг 5 (Ответить).

В моем примере я использую код для примера асинхронных сокетов, предоставленного Microsoft. Я могу отправить строку, и мой сервер может ответить обратно.

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

Я предполагаю, что сервер все еще ожидает обратного вызова от клиента после отправки строки "<ok>" в предыдущем обмене данными. Я никогда не отправлял ничего обратно после "<ok>", так как я делал любую работу, которую хотел сделать. (Как отправить строку "привет").

В этом примере клиент и сервер подключены с обратным вызовом после отправки данных для получения данных с другой стороны. Это необходимо для розеток? Или это как-то связано с асинхронными сокетами?

Если это так, нужно ли мне отвечать сразу же после получения каких-либо данных, что не всегда является моим намерением? Нужно ли пинговать <-> pong взад и вперед, пока у меня не появится работа для подключения через сокет?

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

Answer 1

На разъеме, отправляющий и принимающий каналы полностью отключены и независимы;Пока код написан правильно, вы можете обрабатывать оба полностью независимо, и нет особой зависимости между отправкой и получением - вы можете отправлять только, получать только, или вы можете отправлять и получать отдельно, не ожидая, что вы всегда это делаетеодин потом другой.В очень простых сценариях клиенты, как правило, отправляют, а затем получают, а серверы, как правило, получают, а затем отправляют, но это просто потому, что - это шаблон запроса / ответа (когда инициируется клиентом),не потому, что что-то присуще сокетам.

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