Sockets TCP/IP + Unity

[DbIMok]

вы зря упорствуете в своем заблуждении) но, дело ваше...

[Sality]

А в чем я упорствую?))) Вникать в глубины сишарпа я недумаю лучшим выходом)

Или вы всетаки советуете учить его?

[DbIMok]

после с++ думаю будет не сильно сложно. на простом уровне можно обойтись js, но если хотите плотно использовать возможности .net (сокеты-потоки и т.п.) проще сразу писать на с#

[Груберк]

маразм какой-то... причем тут дебри C# до Socket API? Оно на 99% идентично в любом языке наследнике C... тем более что с С++ (если вы офигенный гуру, что даже сервер на нем умудрились написать) пересесть на С#... это как с табуретки пересесть на кресло, вы даже себя удобнее почувствуете в мягком кресле со встроенным сборщиком мусора.

и сейчас наверное в любую IDE можно к C++ добавить C# и поменяется у вас только синтаксис слегка.

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

Сеть в Юнити через .Net, пространство имен system.Net, там вы найдете уже знакомые вам (по C++): socket, bind, accept, listen...

[Груберк]

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

Например чтоб я мог соединится по адресу и порту, и отправить туда грубо говоря массив данных.

Ласково говоря, а что еще можно отправить кроме данных? Газ?

И так же само, поставить прослушку, на прием каких то данных от сервера.

Модель поведения клиент-сервер предусматривает, что слушает сеть в ожидании клиентов сервер.
Хотя возможно здесь вы хотели описать работу функции recv(...)? Тогда очень грубо, но суть почти передали.

Ведь для работы с сетью нужен отдельный поток.

Зависит от ваших потребностей в сети, это не аксиома, т.к. если подойти к процессу сети поближе, то вы узнаете, что обмен данными идет на уровне ядра ОС и драйверов, без вашего участия. Вы только читаете заполненый буфер, если вам кто-то что-то написал. Поэтому работа основного потока Unity не повлияет на получение данных в буфер, откуда вы их сможете читать в любой момент (хоть в FixedUpdate()).

если я правильно понял унити этого не умеет?

Да и .Net этого по сути не умеет, он просто вызывает методы ОС, предоставляет обертку, поэтому я и написал, что принципиально работа с сетью в разных языках не отличается, т.к. все-равно все языки работают с Native API... (а Berkeley Sockets в своей "БолгенОС" не реализует только полный идиот, которому не нужен метод связи, существующий в 99,999999% ОС)

реализация с потоками тоже все через дотнет?

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

Прошу меня извинить за такой большой ликбез.

P.S. "Не хочу".

[Sality]

спс за мнение.. вы прям меня порвали критикой )
На самом деле я не гуру с++, но написать связку сервер + клиент не так уж и сверх сложно, если задатся целью. Как в принципи и все остальное. Тут главное желание.
Вы правильно сделалли мне замечание, если я хочу быть хорошим програмистом, должен уметь работать на разных языках если требуется... поэтому ваш аргумент был последним, берусь за С#
А вот по поводу потоков, можно ли по подробнее, так как понятное дело что на низком уровне прием и передачу разруливает сама ОС, Но вот прием и обработку нужно делать в отдельном потоке от основной игры, гуи, логики, иначе будет капут.

[Груберк]

Отправить что-то по сокету это даже не верхушка айсберга, а одна снежинка, вы еще стллько граблей встретите и велосипедов изобретете...

Как я и писал выше, достаточно обращаться к буферу сокета N раз в секунду в зависимости от потребностей конкретной игры, а не спамить чтение в отдельном потоке, получая нулевой результат в 999000 случаях из миллиона. Можете делать это в функции fixedupdate() пустого ГО, который у вас в сцене занимается только сетью. Если вы закончили изучение сети на блокирующих сокетах и опасаетесь, что они повесят вам весь поток исполнения, то советую читать дальше и наткнуться на их неблокирующих братьев.

[Sality]

Немного вас непонял... работать с сетью можно и в синхронном режиме, и в асинхронном, но это не меняет проблемы зависания всей игры, во время отработки приема и отправки данных. Я рассуждаю с калакольни С++, если в унити каждый ГО отрабатывается в отдельном потоке, тогда вообще можно горы воротить, и никаких тормозов не будет.

Кстати, на эту тему я хотел узнать, када создается 2 обьекта на сцене, и к ним цепляются 2 разных скрипта. В них допустим фнции Update() вызываются (как я прочитал каждый рендер кадра) так вот эти фнции стартуют в разных потоках*? Вобще вопрос хотелось бы затать глобальнее, по какому принципу вобще срабатывают скрипты или шарповские файлы. В какой последовательностю, и при каких условиях на том или ином обьекте они срабатывают.

Возможно эти вопросы лучше вынести в отдельнуютему?

[gnoblin]

про задержки я понял не совсем,
а вся логика у двух разных го обрабатывается в одном и том же потоке

[Груберк]

Немного вас непонял... работать с сетью можно и в синхронном режиме, и в асинхронном, но это не меняет проблемы зависания всей игры, во время отработки приема и отправки данных. Я рассуждаю с калакольни С++, если в унити каждый ГО отрабатывается в отдельном потоке, тогда вообще можно горы воротить, и никаких тормозов не будет.

А вас не смущает, что у вас на компе работают десятки процессов и куда больше потоков, а процессоров всего 1/2/4? Ваше чтение из буфера сокета займет микросекунды, обработка еще какие-то микросекунды, человек воспринимает 24 кадра в секунду, для избыточного качества достаточно 60 кадров в секунду это 16 миллисекунд времени между кадрами. Времени больше чем достаточно.
То что вы отдельный поток зафигачите не добавит вам в компьютер дополнительного процессора для полнофункциональной параллельной обработки. Потоки не работают параллельно, они просто быстро переключаются.

Кстати, на эту тему я хотел узнать, када создается 2 обьекта на сцене, и к ним цепляются 2 разных скрипта. В них допустим фнции Update() вызываются (как я прочитал каждый рендер кадра) так вот эти фнции стартуют в разных потоках*? Вобще вопрос хотелось бы затать глобальнее, по какому принципу вобще срабатывают скрипты или шарповские файлы. В какой последовательностю, и при каких условиях на том или ином обьекте они срабатывают.

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

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

[Sality]

Как работает поток я прекрасно знаю, и так же знаю как работает процессор. А вот вы меня учите, а по моему сами то и не знаете, Попробуйте принять HTML страничку, с таблицей эдак строк на 500, и вручную распарсите все теги, слова и тд. И вы поймете что означает работа с сетью в 1 потоке с гуи. Принцып описаный вами подходит для микро-алгоритмов. Но как только пойдет инфы больше, пойдут лаги.

Да и вобще, даже если будет сверх скоросная отработка алгоритмов, это называется быдло-код, при котором вы отбираете у программы время на обработку запросов с сети.

спс за аргументы, я перечитываю щас полностю весь гуард по унити.

[Груберк]

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

Ну допустим выделили сеть вы в отдельный поток. Послал вам отправитель "большую информацию" (а раз вы за цифры взялись, то беритесь по уму. Что в вашем понимании "большая информация"?) эдак на 100 КБ, а тут еще сеть плохая и все-такое и подвис ваш поток в ожидании хвоста огромного пакета.
Тут ваш счастливый "гуи" просчитал пиксели на экране и... А дальше хрен... Инфы-то от потока нету, он же еще работает над кусками этого огромного пирога.
И толку вам тут от отдельного потока? Если сеть лагает, то вам даже мульён потоков не поможет.

Вот несколько вариантов:
1) Не допускать пакетов длинной больше MTU
2) Не допускать избыточной информации (если вы собираетесь 256 раз в секунду слать координаты игрока, то вы сеть опять же убьете и никакие потоки вам не помогут)
3) Сделайте ограниченное количество чтений буфера (например прочитать 3-4 пакета и закончить обработку сети до следующей итерации или читать до 1го пакета, который еще не полностью образовался в буфере)

Теперь давайте подумаем вот над чем. Есть разные протоколы. Например TCP и UDP. В чем разница? Разница в том (в нашем вопросе), что используя UDP вы будете читать всегда полный пакет, используя TCP вы можете нарваться на пакет без хвоста (почему? в теорию вдаваться не буду, что бы не раздувать). Это тоже нужно учитывать применимо к 3м вышеуказанным пунктам.

И вуаля, вам будет достаточно иногда заглядывать в буфер сети между отрисовками и корректировать мир для следующей отрисовки, куда уже проще и не быдлокодерски?

P.S. Давайте вспомним самое банальное:

Синтаксис:

Синтаксис: [ Показать ]

Используется csharp

while( msg.message!=WM_QUIT ) // если не сообщение о выходе
{
        // проверяем, есть ли сообщения в очереди
        if( PeekMessage( &msg, NULL, 0U, 0U, PM_REMOVE ) )
        {
                // сообщения есть, обрабатываем их
                TranslateMessage( &msg );
                DispatchMessage( &msg );
        }
        else // иначе занимаемся рендером
        {
                // тут будет код рендера
                // а пока просто очистка экрана
                m_pd3dDevice->Clear(0, NULL, D3DCLEAR_TARGET|D3DCLEAR_STENCIL|
                        D3DCLEAR_ZBUFFER, 0, 0, 0);
                m_pd3dDevice->Present(NULL, NULL, NULL, NULL);
        }
}

Почему игры работают, а не зависают в вечной обработке сообщений капризной Windows?

P.P.S.
Ради интереса покопался в парсерах XML (а мы ведь знаем, что HTML это надстройка над XML?). Нашел pugixml, судя по исходникам однопоточный, скорость работы ну как минимум 3000 тегов в миллисекунду (может конечно и ошибаюсь, но 500 тегов на этом фоне все-равно такая ерунда...)

[Sality]

Хм... а при чем тут гуи к сетевому потоку? даже если сетевой поток зависнет в цикле for(;;) гуи как не глючило так и не глючит. оно будет отрисовывать пиксели, которые ему приходят от гуи потока. Вот как раз если сокет зависнет в ожидании хвоста пакета, игра остановится.. вернее остановится перемещение других обьектов в игре, но наш перс должен свободно бегать, так как все движения отрабатываются локально.
м.... я понял вашу мысль, вы заблуждаетесь, нельзя игру привязывать к сетевым данным. Игра не должна чувствовать сеть вообще, нету данных от сети, заблокировали игру, есть данные, играем.

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

[Груберк]

ГУИ я взял образно, потому что это понятие в наш разговор ввели вы. Вы правильно говорите, есть данные игра идет, нет данных игра висит. Теперь смотрите: есть данные в буфере сокета - читаем, нет данных или не хватает для полной обработке пакета - завершаемся и ждем следующей итерации, это куда более гуманно к нагрузке на процессор, чем пустые вызовы функции чтения в отдельном потоке. Вы мне пытались доказать, что сеть по-любому нужно выделять в отделять в отдельный поток, а я вас пытаюсь убедить, что в большинстве случаев этого просто не требуется.

Достаточно 30 раз в секунду проверять состояние сетевых буферов, для обеспечения плавной игры. Данного функционала можно добиться при помощи функции FixedUpdate(). Вот и все, проблема решена. Не верите? Попробуйте 30 раз за секунду щелкнуть мышкой. Вот когда научитесь, тогда начнете замечать, что ваша игра работает не плавно
И я даже больше скажу, что достаточно 30 раз в секунду обновлять состояние мира на сервере, что бы все игроки чувствовали плавную игру, а остальное время процессора посвятить чему-нибудь полезному, а не пустому вызову функции, нулевой результат которой вы можете заведомо предсказать.
(Очень распространенное мнение, что чем больше FPS, тем лучше, хотя как показывает практика, что достаточно 60 кадров в секунду, что бы чувствовать себя комфортно, а все что свыше них просто греет вашу видеокарту и выбрасывается во вселенную в тот момент, когда ваши глазные рецепторы "моргнули")

Игра не должна чувствовать сеть вообще

Вот вам ситуация, 2 игрока с помповыми ружьями нацелились в мошонку друг-друга и Игрок 1 нажал спусковой крючок. По вашей логике яйца Игрока 2 покатились по полу, выстукивая по новой испанской плитке мотивы Led Zeppelin.
Но по иронии судьбы пакет Игрока 1 попал на маршрутизатор, который обрабатывал пакет, содержащий сцену "Сиська крупным планом" порно фильма "Белоснежка и Семь принцев 3D", просмотром которого занимался Игрок 978, ожидая своей очереди в игре. И поскольку программное обеспечение для маршрутизатора писали люди, которые любят Белоснежку, а маршрутизатор был очень загружен, то железка выбрала пакет Игрока 978, дабы тот мог спокойно завершить свои физиологические процессы.
В тот же момент, на другом конце страны, Игрок 2 в панике щелкает мышкой, раздается выстрел и вот мы слышим уже знакомый мотив Led Zeppelin (Поскольку серверу пакет Игрока 2 пришел раньше пакета Игрока 1). Представьте удивление Игрока 1, который уже открыл бутылку шампанского, обмывая свою победу, как вдруг на его экране нарисовалась надпись: You Lose!
Вот вам и "игра должна идти дальше, не обращая внимания на сеть". Побойтесь того, что эта недопитая бутылка шампусика может оказаться в заднепроходнем отверстии программиста сети данной игры.

И еще хочу обратить ваше внимание, что происходит при конекте к серверу? зависает поток, в котором происходит этот конект.

Вы напрямую управляете конектом или вызываете функцию и ожидаете ее результата от ОС? Мне кажется второе. Значит есть возможность неблокируемого коннекта? И ведь правда! Дайте задачу своей системе, скормите ей функцию обратного вызова, которая установит флаг "Соединение удалось" и продолжайте заниматься своими делами, проверяя попеременно этот флаг. Уверяю вас, что проверяя его 30 раз в секунду, вы даже не заметите тех 32 мс, которые прошли от момента установки флага до момента следующей его проверки.

[Sality]

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