|
Сетевая библиотека вместе!
| |
| Povstalez | Дата: Четверг, 27 Ноября 2014, 19:15 | Сообщение # 1 |
постоянный участник
Сейчас нет на сайте
| Здравствуйте уважаемые обитатели форума,
Я недавно начал делать сетевую библиотеку на C# как под обычные консольные приложения, так и под игровой движок Unity3d. Хотел бы попросить помощи, а именно:
Посмотреть код и по возможности сделать какие-то поправки в нём. Давайте делать сетевой движок своей мечты вместе!
Ссылка на codeplex
|
|
|
| |
| programMain | Дата: Пятница, 26 Октября 2018, 04:56 | Сообщение # 2 |
частый гость
Сейчас нет на сайте
| Прости, но я посмотрев только один класс севера понял - что это совсем не то... Смотри, ты управляешь потоками сам = медленно и ресурсоемко. При 200 + клиентов с обильной активностью все упадет). Используй асинхронные сокеты с callbacks и будет тебе радость), а про udp забудь. Если это не вещание телевизионное или передача каких либо файлов, то используй TCP протокол.
|
|
|
| |
| Abel399 | Дата: Пятница, 26 Октября 2018, 07:00 | Сообщение # 3 |
Surpass your limits. Right now.
Сейчас нет на сайте
| programMain, откуда такие выводы про UDP? Создается впечатление, что TCP > UDP, когда это далеко не так )0
Это я к тому, что для UDP есть замечательная ENet. Вот создать обертку над ней для удобного использования в Unity + фичи, было бы интересной идеей.
Ninja Slayer - 2D Physics Puzzle [cancelled]
|
|
|
| |
| programMain | Дата: Пятница, 26 Октября 2018, 15:33 | Сообщение # 4 |
|
частый гость
Сейчас нет на сайте
|
Нет, наоборот. Просто если бы ты хоть раз сниффер открывал бы, или делал бы нагрузочный тест на сервера, тогда бы ты понял в чем проблема.
|
|
|
| |
| Abel399 | Дата: Воскресенье, 28 Октября 2018, 05:26 | Сообщение # 5 |
|
Surpass your limits. Right now.
Сейчас нет на сайте
| programMain, хорошо, у вас свой опыт, у меня свой. На моем опыте у TCP огромный оверхед по траффику, проблемы с p2p из-за чрезмерной секурности -> ниже пропускная способность. Все проблемы UDP обычно решаются построением своего протокола поверх UDP, либо использование уже готового решения.
Единственная проблема, которую сложно решить из-за принципа работы протокола - отладка и поиск проблем в архитектуре сети. Если вы это имели ввиду, то хорошо, ваша правда. Но задумайтесь почему же тогда так много тайтлов используют связку TCP + UDP, где второй играет вовсе не последнюю роль?) Это не просто так людям в голову ударило и есть на то вполне очевидные причины.
P.S> Вообще, необходимо понимать, что нельзя на архитектуру приложения построенную поверх TCP накрутить UDP, обратное тоже верно. При проектировании нужно учитывать особенности протокола. Можно провести аналогию с СУБД и ACID, где требуется атомарность, устойчивость, изоляция и согласованность -> получаем консистентность передаваемых данных даже с UDP. Другой момент, что на это может не хватить квалификации, но это уже тема отдельной дискуссии.
Ninja Slayer - 2D Physics Puzzle [cancelled]
Сообщение отредактировал Abel399 - Воскресенье, 28 Октября 2018, 05:33 |
|
|
| |
| programMain | Дата: Вторник, 06 Ноября 2018, 02:25 | Сообщение # 6 |
|
частый гость
Сейчас нет на сайте
| Цитата Abel399 (  ) Вообще, необходимо понимать, что нельзя на архитектуру приложения построенную поверх TCP накрутить UDP, обратное тоже верно. При проектировании нужно учитывать особенности протокола. Можно провести аналогию с СУБД и ACID, где требуется атомарность, устойчивость, изоляция и согласованность -> получаем консистентность передаваемых данных даже с UDP. Другой момент, что на это может не хватить квалификации, но это уже тема отдельной дискуссии.
Зачем строить свой протокол над UDP, что бы добиться работы схожей с TCP? Если ты и делаешь свой протокол, который решает проблему упорядоченной доставки данных и защиты их - то поверь, люди которые сделали протокол TCP - сделали это лучше. Я не говорю не использовать UDP - я говорю использовать его правильно и по назначению. А UDP использовали в играх в конце 1990 - начале 2000-х, когда скорость инета была мала, тогда и можно было бы почувствовать разницу в скорости. Сейчас - не почувствуешь...
|
|
|
| |
| qazer | Дата: Вторник, 06 Ноября 2018, 09:38 | Сообщение # 7 |
Borey Games
Сейчас нет на сайте
| Затем, что не для всех задач нужна упорядоченность. TCP тебе не хватит для real-time шутеров и стратегий.
Если теряется n-ый пакет, то ты переотправляешь его, несмотря на то что, возможно есть более актуальные данные. Соответственно из-за упорядоченности и принимающая сторона не может воспользоваться данными которые были отправлены позже но пришли раньше, что мы ждём, например, старый затерявшийся пакет. Алгоритм Нейгла также может помешать работе в таких играх.
Почитайте статью и этот блог в целом, разумно пишет
https://gafferongames.com/post/udp_vs_tcp/
В то же время для пошаговых и медленных игр tcp подходит прекрано
Добавлено (06 Ноября 2018, 09:47)
---------------------------------------------
Upd. опять же сочетать tcp и udp - посредственный вариант. Сложнее отлаживать, данные могут идти через разные сетевые интерфейсы, tcp может негативно со своей переотправкой влиять на udp, который используется для более критичных ко времени данных. Посему городят свой стек поверх UDP. И здесь бывают исключения, но они только подтверждают правило
Сообщение отредактировал qazer - Вторник, 06 Ноября 2018, 09:51 |
|
|
| |
| drcrack | Дата: Вторник, 06 Ноября 2018, 09:56 | Сообщение # 8 |
|
старожил
Сейчас нет на сайте
| Цитата Используй асинхронные сокеты с callbacks и будет тебе радость), а про udp забудь.
у меня ж глаз задергался когда я это прочитал))
1. не используй асинхронные сокеты с callbacks, они не предназначены для высокой нагрузки
2. tcp не предназначен для реалтайм игр, не используй его
Цитата Зачем строить свой протокол над UDP, что бы добиться работы схожей с TCP?
Обьясняю почему — потому что иногда тебе нужна гарантированная доставка, иногда важен порядок, иногда и то и другое, а иногда наоборот ничего
Например ты отправляешь скажем позицию чего-то 30 раз в секунду
Что случится если 1 пакет потеряется?
Да ничего, в следующем уже будет актуальная инфа, пересылать старые данные нет никакого смысла
Или другой пример — за короткий промежуток времени на карте спаунится 10 обьектов, например, вражеских ракет, и ты посылаешь 10 пакетов клиентам
Разве тебе важен порядок в котором они будут обработаны? Нет, более того, даже если 1 из пакетов не дойдет, клиент хотя бы получит 9 остальных обьектов без задержек, а потерянный может быть переслан отдельно
В случае же TCP при потере одного из пакетов все последующие ждали бы пока он будет повторно отослан и принят клиентом, что в случае хотя бы 100 мс пинга будет восприниматься игроками как реальный лаг
В общем, проблема TCP в том что ты не можешь управлять фичами, ты всегда получаешь их все, даже когда они не просто не нужны, а даже вредны
Поэтому для реалтайм игр всегда используют UDP (кроме браузерок конечно где это технически невозможно)
TCP часто использует как основное соединение для авторизации, покупок, функций типо выбора персонажа, чата, и тд., но это не правило, кастомные протоколы на основе UDP тоже норм.
PS Мы воскресили тему 2014 года 
Сообщение отредактировал drcrack - Вторник, 06 Ноября 2018, 10:23 |
|
|
| |
| programMain | Дата: Вторник, 06 Ноября 2018, 16:02 | Сообщение # 9 |
|
частый гость
Сейчас нет на сайте
| Господа, я писал на работе оператор фискальных данных, 500 транзакций в секунду. Асинхронный сервер TCP справился на ура.... Вы по-моему не совсем компетентны в данной теме... 15000 пользователей, канал гигабитный. Проблем с ним вообще нет. Хочешь сказать твоя игра сильней сеть нагрузит? Сомневаюсь.... Или вы начитались что UDP для игр а TCP в топку? Сейчас не то время, что бы как раньше выбивать миллисекунды для скорости работы программы...
|
|
|
| |
| zhuravelsv | Дата: Вторник, 06 Ноября 2018, 16:31 | Сообщение # 10 |
|
почетный гость
Сейчас нет на сайте
| Цитата programMain ( ) 500 транзакций в секунду
Цитата programMain ( ) 15000 пользователей
Это разве много?  Https вон гораздо более нагружен чем ТСП, но обработка 500 хттпс запросов в секунду это тоже не большая проблема. Я это к тому что это не какой-то хайлоад с кучей данных или высокой загруженностью, а вот если бы ты попытался 100к пользователей с тикрейтом 30 раз в секунду обработать тсп уже может быть и не был бы хорошим вариантом
Разработка программного обеспечения для ОС Windows и Android, клиент-серверные, облачные приложения, работа с БД и многое другое - https://www.weblancer.net/users/zhuravelsv/
Сообщение отредактировал zhuravelsv - Вторник, 06 Ноября 2018, 16:32 |
|
|
| |
| programMain | Дата: Вторник, 06 Ноября 2018, 16:42 | Сообщение # 11 |
|
частый гость
Сейчас нет на сайте
| Зачем? Все компании (включая игровых) имеют дата центры, 10 серверов поставил и распределил нагрузку. Все... 15000 бы набрать . Наберешь столько - будут деньги с игры на второй сервер - еще на 15 тысяч))).
|
|
|
| |
| drcrack | Дата: Вторник, 06 Ноября 2018, 18:22 | Сообщение # 12 |
|
старожил
Сейчас нет на сайте
| Цитата Сейчас не то время, что бы как раньше выбивать миллисекунды для скорости работы программы...
тем не менее все современные сетевые реалтайм игры, от шутеров до мморпг, используют UDP для передачи чувствительных к задержкам данных
Цитата Господа, я писал на работе оператор фискальных данных,
Цитата Вы по-моему не совсем компетентны в данной теме...
тут ты прав, я вот лично не очень компетентен в написании операторов фиксальных данных, поэтому и не лезу на форум 1с с глупыми советами
Сообщение отредактировал drcrack - Вторник, 06 Ноября 2018, 18:27 |
|
|
| |
| Эргалон | Дата: Вторник, 06 Ноября 2018, 18:27 | Сообщение # 13 |
Вездесущий
Сейчас нет на сайте
| Ну а что если например при использовании UDP, нужно обязательно получить пакет, но он не приходит? Банальный пример, прокачиваем способность персу, пакет с результатом прокачки не пришел. Клиент не знает что прокачал способность. Не было ни ошибки, ни оповещения о удачной попытке. Или например взять игровой автомат. Крутишь барабан и если пакет не придет, барабан будет крутиться вечно. Или я чего-то не понимаю?
Кубариум
Rise of the dark lords
|
|
|
| |
| drcrack | Дата: Вторник, 06 Ноября 2018, 18:29 | Сообщение # 14 |
|
старожил
Сейчас нет на сайте
| тут все просто, ты либо используешь второе соединение (tcp) для данных где важна надежность, либо пишешь свой протокол поверх udp, оба способы актуальны, видел и то и другое во многих современных играх
|
|
|
| |
| Эргалон | Дата: Вторник, 06 Ноября 2018, 18:57 | Сообщение # 15 |
|
Вездесущий
Сейчас нет на сайте
| Ну то есть upd хорошо используется там, где происходит непрерывная передача данных в активных действиях. Например если есть поле боя, на нем 1000 юнитов. Все перемещаются, всё норм.
На TCP это будет выглядеть так:
Пакеты не пришли, когда они приходят то юниты быстро перемещаются из одной точки в другую до последнего полученного положения.
На UPD:
Пакет не дошел. Юниты просто телепортируются к положению, полученным с последнего пакета.
Даже и не знаю, что выглядит привлекательнее))
Кубариум
Rise of the dark lords
|
|
|
| |
| programMain | Дата: Вторник, 06 Ноября 2018, 19:59 | Сообщение # 16 |
|
частый гость
Сейчас нет на сайте
| Цитата Эргалон ( ) Ну то есть upd хорошо используется там, где происходит непрерывная передача данных в активных действиях. Например если есть поле боя, на нем 1000 юнитов. Все перемещаются, всё норм.
На TCP это будет выглядеть так:
Пакеты не пришли, когда они приходят то юниты быстро перемещаются из одной точки в другую до последнего полученного положения.
На UPD:
Пакет не дошел. Юниты просто телепортируются к положению, полученным с последнего пакета.
Даже и не знаю, что выглядит привлекательнее))
кто двигает юниты по пакетам передачи? один пакет где начал движение, второй где закончил, на клиенте считаешь путь и двигаешь.... Так не? не канает? или вы на каждый пиксел пакеты передавать собираетесь?
|
|
|
| |
| Эргалон | Дата: Вторник, 06 Ноября 2018, 20:10 | Сообщение # 17 |
|
Вездесущий
Сейчас нет на сайте
| programMain, Это так, образно говоря) Вообще хотел привести пример fps-а, просто что-то вархаммер вспомнил) Так или иначе, каждого юнита может нужно по механике двигать при помощи клавиатуры, а не тикать на карте мышкой, чтобы проложить путь) Тогда этот пример вполне себе имеет место.
Кубариум
Rise of the dark lords
Сообщение отредактировал Эргалон - Вторник, 06 Ноября 2018, 20:13 |
|
|
| |
| drcrack | Дата: Вторник, 06 Ноября 2018, 20:24 | Сообщение # 18 |
|
старожил
Сейчас нет на сайте
|
UDP: в большинстве случаев игрок ничего не заметит, потому что через 33 мс приходит новый пакет, а интерполяция сглаживает отрицательные эффекты от потери предыдущего
TCP: вся игра замирает на 50-200 ms, никакие новые данные с сервера не обрабатываются пока не будет переслан и подтвержден потерянный пакет (не только позиции, но также используемые врагами способности, уровень здоровья, и тд и тп)
|
|
|
| |
| zhuravelsv | Дата: Вторник, 06 Ноября 2018, 20:30 | Сообщение # 19 |
|
почетный гость
Сейчас нет на сайте
| Цитата programMain ( ) Зачем? Все компании (включая игровых) имеют дата центры, 10 серверов поставил и распределил нагрузку. Все... 15000 бы набрать . Наберешь столько - будут деньги с игры на второй сервер - еще на 15 тысяч))).
это не аргумент, кстати, почему обычно видео- и аудио- в реалтайм протоколах передачи данных используют как базу udp протокол? (SIP,RTP,...) 
Разработка программного обеспечения для ОС Windows и Android, клиент-серверные, облачные приложения, работа с БД и многое другое - https://www.weblancer.net/users/zhuravelsv/
Сообщение отредактировал zhuravelsv - Вторник, 06 Ноября 2018, 20:30 |
|
|
| |
| programMain | Дата: Вторник, 06 Ноября 2018, 21:37 | Сообщение # 20 |
|
частый гость
Сейчас нет на сайте
| Так я и говорю, используйте udp для передачи данных (файлы, видео, аудио), для игр подойдет и tcp. У нормально написанной игры, на одного пользователя приходится мало трафика). И это аргумент. Давай проще так - ты сервер на UDP скинь, я замерию против своего TCP на работе нагружу их по несколько тысяч пользователей, будут просто передавать несколько строк друг другу, и посмотрим какая производительность будет и сравним так сказать... Кстати, ребят кому грамотная проверка на нагрузку нужна - обращайтесь. Загружу ваш сервак 10+к пользователями, отчеты заскриню)))) Добавлено (06 Ноября 2018, 21:44)
---------------------------------------------
Цитата Эргалон ( ) programMain, Это так, образно говоря) Вообще хотел привести пример fps-а, просто что-то вархаммер вспомнил) Так или иначе, каждого юнита может нужно по механике двигать при помощи клавиатуры, а не тикать на карте мышкой, чтобы проложить путь) Тогда этот пример вполне себе имеет место.
В fps таже тема) замеряется начало движения - конец движения, рассчитывается сколько ты шел, начало движения мыши и конец. Считается все клиентом, а сервер только проверяет не соврал ли клиент и рассылает другим)))
|
|
|
| |
|
