Мне нужно реализовать клиентский/серверный мессенджер с использованием чистых сокетов в Java lang.
Сервер должен обслуживать большое количество клиентов, и мне нужно решить, какие сокеты следует использовать - TCP или UDP.
Спасибо, Коста.Что лучше для обмена мгновенными сообщениями TCP или UDP?
TCP
Причина:
TCP: «Существует абсолютная гарантия того, что данные, передаваемые по-прежнему нетронутыми и прибывает в том же порядке, в котором он был отправлен»
UDP: «Нет гарантии, что отправленные сообщения или пакеты будут доступны вообще».
Узнайте больше на сайте: http://www.diffen.com/difference/TCP_vs_UDP
ли вы хотите, чтобы ваше сообщение в чате, возможно, потерял?
Редактировать: Я пропустил часть о «большой программе чата». Я думаю, что из-за характера чат-программы он должен быть TCP-сервером, я не могу представить фактический текстовый контент, отправленный пользователями по протоколу UDP.
Максимальный предел для серверов TCP - это 65536 соединений одновременно. Если вам действительно нужно пройти этот номер, вы можете создать диспетчерский сервер, который будет отправлять входящие соединения на соответствующий сервер в зависимости от текущих загрузок сервера.
На самом деле я не хочу, чтобы сообщение было потеряно, но любое ограничение сокетов, которое может создать сервер? Насколько я понимаю, TCP открывает сокет для каждого подключенного клиента TCP. – Wizit
Я бы не беспокоился о ограничениях нагрузки на вашем сервере, если вы не планируете внедрять смехотворно большую программу чата. Максимальный предел на сервере TCP - 65536 соединений. И да, вы должны иметь открытое соединение с каждым клиентом. –
Это зависит от того, должен ли пользователь знать, были ли сообщения доставлены на сервер. UDP-пакеты не имеют неотъемлемого подтверждения. Если клиент отправляет IM-сообщение на сервер, и он потеряется в пути, ни клиент, ни сервер не будут знать об этом.
(Короткий ответ «использование TCP» ... но это стоит продумать последствие дизайна для себя.)
TCP даст вам надежность, что, безусловно, желательно, когда во время обмена мгновенных сообщений - вы не хотел бы, чтобы сообщения были удалены во время конвертации.
Однако, если вы намереваетесь использовать групповые сообщения, тогда вы можете использовать mulitcast. В таких случаях UDP будет правильным chioce, поскольку UDP может обрабатывать точки для многоточечного соединения. Использование TCP для многоадресных приложений было бы затруднительным, так как теперь отправителю пришлось бы отслеживать повторные передачи/скорость передачи для нескольких приемников. Одной из альтернатив может быть использование TCP для двухточечного чата и использование UDP для группового обмена сообщениями.
Вы можете использовать оба этих параметра. Используйте TCP для обмена фактическими сообщениями (так что потеря данных и потоковая передача больших сообщений (например, содержащих jpegs и т. Д.) Возможны. Используйте UDP только для отправки коротких сообщений «connectNow» клиентам, для которых есть сообщения в очереди. может иметь такие состояния, как (NotLoggedIn, TCPconnected, TCPdisconnected, LoggedOut) с различными тайм-аутами для управления переходами состояния, а также с обычными событиями обмена сообщениями. Сообщение UDP «connectNow» должно указывать клиентам в «TCPdisconnected» для подключения и, таким образом, «TCPconnected», где они будут находиться, обмениваясь сообщениями, пока какой-то таймер неактивности не даст клиенту отключить на данный момент. Это, конечно, было бы ненадежным, и поэтому вы можете повторить сообщение «connectNow» каждые X секунд в течение N раз пока клиент не подключится. Клиент должен в любом случае попытаться опросить каждые X минут, на всякий случай ...
Это зависит от того, есть.Единственное требование, которое вы нам дали, «большое количество клиентов» в основном бессмысленно, потому что мы не знаем, считаете ли вы 800 клиентов «большим числом» или 16 000. –
Это может быть десятки тысяч клиентов за одно и то же время – Wizit