Здравствуйте. Делаю UDP чат. Возник вопрос как лучше отправить сообщение всем.

Допустим в чате авторизовались(послали логин/пароль) 3 пользователя. Записывать адрес каждого и потом в цикле с помощью sendto отправлять каждому? Ведь UDP не устанавливает соединение.

Или как это делают нормальные люди?)

У меня есть одна шутка про UDP. Но, боюсь, она до вас не дойдёт...

Мог бы и написать, раз уж постишь. Может дошла бы) Я не совсем тупой как бы) Протокол, вроде знаю.

Это сообщение отредактировал(а) KPEHDEL - 22.9.2012, 15:47

Ужэ не дошла, успокойтесь.

tzirechnoy, дошло только после того как разжували)

Вопрос актуален.
Сейчас записываю адреса авторизовавшихся в sockaddr_in users_online_addr[10]; И потом в цыкле отправляю.
Но это ведь не нормально да?

Это сообщение отредактировал(а) KPEHDEL - 23.9.2012, 10:56

Если у Вас ограничение в 10 пользователей, то почему не использовать TCP?

Добавлено через 2 минуты и 22 секунды

Всё зависит от логики, которую Вы хотите воплотить. 

KPEHDEL, тут шутка юмора заключалась в том что она не дошла бы до вас не потому что вы тупой, а потому, что протокол UDP не дает никаких гарантий (в отличии от TCP) по доставке пакетов.

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

Ещё есть: люди делятся на 10 категорий - те кто понимает двоичную систему и тех, кто нет

Сервер какой-то предусматривается?

Отправить можно по очереди всем через sendto, как извращение - использовать мульти и широковещательные пакеты.

По поводу гарантии доставки UDP сообщений - в локалке скорее всего потерь не будет (если нет переходов 10/100/1000 на узлах и приложений забивающих каналы).
Если гарантии нужны, рекомендую попридумывать какой-то механизм подтверждений, в течении 2 дней, потом посмотреть на TCP.



Это сообщение отредактировал(а) semibug - 23.9.2012, 10:05

Спасибо за шутки)

Ограничение не в 10 пользователей. Просто пока написал столько.


В моей задаче больше подходит UDP. Полная гарантия доставки не нужна, так как если пакет будет доставлен сильно позже, он уже не будет нужен. 


Да, сервер предусматривается, работать должно не только в локалке.


Пока так и сделал, но это не красиво.



Пойду подробнее читать об этом.

Спасибо за ответы, если будут ещё варианты, пишите.

Интересно как же делают в онлайн играх сделанных на udp, думаю там не отправляют по очереди в цикле с помощью sendto  

Именно отправляют, именно в цыкле (ну, с некоторым распараллеливанием, которое распараллеливание вообще, и не зависит от sockets). 
Мультикаст, по сути, пока не работает -- то есть если это полностью твоя сеть, с твоими роутерами и свитчами, и у тебя есть власть над админами конечных точек -- то есть шанс это настроить. Если клиент, который владеет сетью и конечными точками, готов заплатить тебе 100500 баксов за твоё решэние -- тожэ. В средне-нормальной IP-сети -- нет, он просто не работает.
Броадкаст -- это в рамках одного сегмента сети, и поэтому ни для чего кроме настройки сети в этом сегменте неприспособлен.

Добавлено через 2 минуты и 25 секунд
И самое важное: дажэ локальная сеть с 1% потерь -- это хреновенькая локальная сеть, но работающая и встречающаяся нередко. 0.1% потерь -- это сплошь и рядом. Если не хочешь, чтобы каждая 300-я фраза молча пролетала мимо клиента -- надо что-то делать.

Ну в принципе представление я получил, то есть если ориентация не только на сеть, то в цикле и с распараллеливанием.


Что-то делать для уменьшения вероятности потери нужного пакета в любом случаи прийдётся, но это уже немного позже. 

Спасибо за ответы.  

Пожалуйста, объясните, почему. И как Вы хотите реализовать отсоединение клиента от чат-сервера.

Видеочат - конференция? Если просто текст, тогда непонятно почему UDP лучше.

В универе скоро будет задание, сделать мини игру на сокетах. Ориентация при моём выборе идёт не на чат, просто решил, что стоит начать с консольного чата.

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

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

Возможно буду использовать UDP совместно с TCP, для разных подзадач. Также сейчас читаю о RUDP.

Кстате моё мнение, что именно для чата, TCP подошёл бы больше, так как в чате важнее не скорость, а гарантия. Возможно для чата его и буду использовать.

Однако сейчас работаю с UDP, следовательно вопросы пока о UDP.


Со стороны клиента при отправке соответствующей команды.
Со стороны сервера, в качестве проверки, отправка клиенту запроса(не один раз), на который клиент должен ответить, иначе дисконнект.

В догонку задам маленький вопрос:
Сделал два потока, чтобы приём и отправка сообщений не мешали друг другу.
Функция потока:


Метод в котором вызывается второй поток:


Так вот, созданный второй поток работает нормально.
А цикл while в отвечающий за приём работает не нормально, нельзя сказать, что не работает вовсе.
Происходит следующее:
Сначала 1 раз выводится test.
А потом работает только второй поток. Иначе бы сообщением "test" заспамило, а также я получал бы сообщения от сервера.

Подскажите пожалуйста в чём дело. Заранее спасибо.

PS: Наверное тему правильнее было создать в разделе C/C++: Сети. Если так перенесите пожалуйста.

Это сообщение отредактировал(а) KPEHDEL - 23.9.2012, 22:20

корейцы мутят ммохи на TCP и тащат)  UDP не очень, просто он проще

• от сервера не приходят пакеты
• ошибка в коде Reception_from_server()

Я склоняюсь к первому варианту...

Предпочитаю брать пример с valve, Blizzard и т.д. Из не популярных могу привести игру War§ow, надо отдать должное реализованной замечательной синхронизации.



Не совсем... Если делать что-то серьёздное на UDP, то простоты будет мало и прийдётся делать велосипеды. А это отнюдь не проще.


Ошибка была во втором варианте(может и не только), спасибо за ответ. Странно, что я сам не усмотрел. 

Это сообщение отредактировал(а) KPEHDEL - 24.9.2012, 16:04

Только вот не пойму в чём она заключается.
Есть метод Authorisation.Auth(); - он запрашивает логин и пароль пользователя, отправляет серверу, если логин и пароль верны, сервер отвечает. При этом используется та же самая Reception_from_server().
В Reception_from_server() сделал несколько cout для наглядности:


 Что мы видим:
Пользователь вводит логин пароль, вызывается:


В консоль при вызове Reception_from_server() выводит:

Reception_from_server()  - отработала успешно.
Далее вызывается Winsock.messaging();.
Которую я приводил ранее.
Консоль выводит:

Если закоментить вызов Reception_from_server(), то оба потока работают правильно.
Таки понятно, что стопится на строчке 

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

С нетерпением жду вариантов.

Это сообщение отредактировал(а) KPEHDEL - 25.9.2012, 10:29

...

Это сообщение отредактировал(а) Леопольд - 24.9.2012, 21:38

Не знаю, какому коду верить, но (int *)sizeof(&server_addr) - конструкция-катастрофа.



Могу лишь снова предположить, что от сервера ничего не поступало   
Это может быть связано с тем, что Вы не дозалогинились на сервер (одного логина/пароля может быть мало, и сервер ожидает от вас ещё какой-нибудь информации, и пока Вы её не пришлёте, он будет молчать). А, может, в  Winsock.Sending_to_server(); Вы посылаете нечто такое, на что сервер не отвечает... А, может, после первой передачи Sending_to_server у Вас попортился адрес сервера в server_addr, и Вы шлёте не туда (по крайней мере, используйте разные экземпляры этой структуры на приём и на передачу)? Кто знает...


В любом случае стоит подсмотреть сетевой трафик каким-нибудь сниффером (например, Ethereal/WareShark), чтобы убедиться, что ответы от сервера есть (или даже что после регистрации на сервере Вы шлёте UDP по нужному адресу). И уже тогда начинать искать программную ошибку   

Естественно, это я просто скопировал не то.

Ошибка была на стороне сервера. Всем спасибо.