Расширение .Net Socket для поддержки ACK и чата?

Question

Расширение .Net Socket для поддержки ACK и чата?

1

У меня есть сервер, который может обрабатывать множество клиентских запросов.

Сервер использует Socket и TcpClient - для каждого клиента он открывает новый поток.

Каждый клиент отправляет данные на сервер и ответ сервера.

Но КАК я "отправляю данные":

Клиент: отправляет байт, который представляет: "Я хочу отправить данные",
Сервер: отправляет Ok Я согласен (1 байт ack)
Клиент: отправляет количество байтов длины данных
Сервер: отправляет Ok, я могу справиться с этим
Клиент: отправляет все данные
Сервер: отправляет Ok

Я могу отправлять файлы

Все это отлично работает.

Вопрос

Здесь возникает проблема:

Эти команды (которые я написал) являются действиями пользователя.

Теперь мне нужно добавить чат в этот экран действий

Это не проблема:

Я открою новый поток, который всегда будет в режиме прослушивания сообщений

Но:

Этот поток, который всегда будет слушать, также перехватит сообщения Ack (которые я написал выше) с сервера!

Я не хочу открывать новый канал связи только для чата.

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

Как я могу (в идеале) решить эту проблему? Я в неправильном направлении?

Royi Namir 01 нояб. 2014, в 16:04

Источник

0

Учитывая язык, который вы используете, он звучит так, как будто вы не хотите использовать TCP/IP а вместо этого протокол более высокого уровня, написанный для необходимого вам уровня абстракции и надежности. Учитывая масштаб проблемы, которую вы поставили, я бы предложил использовать HTTP/REST качестве протокола высокого уровня.
Aron 01 нояб. 2014, в 15:07

Теги:

c#

multithreading

.net

sockets

tcpclient

1 ответ

Ещё вопросы

Учитывая язык, который вы используете, он звучит так, как будто вы не хотите использовать TCP/IP а вместо этого протокол более высокого уровня, написанный для необходимого вам уровня абстракции и надежности. Учитывая масштаб проблемы, которую вы поставили, я бы предложил использовать HTTP/REST качестве протокола высокого уровня.

usr · Accepted Answer · 2014-11-01T13-02-00.000Z

2

Лучший ответ

Если вы не хотите открывать новое соединение для чата, вам придется иметь дело с более сложным проводным протоколом:

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

Нет смысла читать из одного TCP-соединения с несколькими потоками. TCP не основан на сообщениях. Байты, которые являются входящими, могут быть разбросаны произвольно по потокам. Один поток должен выяснить, какой тип данных подходит и отправить его.

usr 01 нояб. 2014, в 13:02

0

+1 Просто чтобы убедиться: когда вы говорите: это не имеет смысла - вы относитесь к теме «прослушать второй поток», верно? не для "сервер открывает новую тему для каждого клиента", не могли бы вы подтвердить?
Royi Namir 01 нояб. 2014, в 15:06
0

Да. Открытие нового потока для каждого клиента абсолютно безопасно.
usr 01 нояб. 2014, в 15:10
0

Хорошо, но как я могу «передать данные фрейма сообщения и сообщение чата таким образом, чтобы сервер мог выяснить, какой из них проходит прямо сейчас» - я посылаю вам данные (вы как сервер). В середине процесса ACK Джон может отправить мне сообщение. что теперь ?
Royi Namir 01 нояб. 2014, в 15:13
0

Вы можете сделать так, чтобы клиент предварительно добавлял "chat:" для сообщения чата и "data:" для данных. Таким образом, сервер может узнать.
usr 01 нояб. 2014, в 15:13
0

На стороне сервера это не проблема. Сервер знает, какое сообщение к чему. как я сказал в первом пункте: каждый клиент сообщает серверу: я собираюсь отправить X (файл / msg / ...). Сервер знает тип каждого сообщения. моя проблема на стороне клиента! ответы от сервера будут смешаны с сообщениями chae и ACKS. USR, я буду рад, если вы сможете предоставить образец / фазу, чтобы сказать вам правду, я застрял на этом
Royi Namir 01 нояб. 2014, в 15:24
0

Вы можете сделать то же самое с сервером. Сделайте сервер префиксом каждого сообщения с ответом. Если вам нужно сопоставить запросы и ответы, сделайте так, чтобы клиент отправлял числовой идентификатор для каждого запроса. Затем сервер может вернуть этот идентификатор вместе с ответом. Таким образом, вы можете сопоставить их.
usr 01 нояб. 2014, в 15:42
0

Usr Ok, я сделал что-то вроде этого: клиент отправляет на сервер только токены команд (фактически, байт) и прикрепляет GUID к каждому токену. Я держу эти руководства и сообщения в словаре. затем в другом потоке клиент прослушивает ответы с сервера. затем, если сервер отвечает: «Хорошо, вы можете отправить мне сообщение» - я иду в словарь и извлекаю MSG через его GUID и отправляю сообщение на сервер. Но теперь у меня есть другая проблема: что, если в середине процесса отправки файла пользователь отправляет другой токен команды: «отправить ФАЙЛ» до того, как он завершит отправку сообщения?
Royi Namir 01 нояб. 2014, в 19:26
0

Как он мог отправить две вещи одновременно? За один раз можно записать только один поток в один и тот же сокет. Вы должны сериализовать эти сообщения вовремя. Если передача файла слишком велика, вы должны разделить его на части.
usr 01 нояб. 2014, в 19:42

Показать ещё 6 комментариев