Понял, спасибо

Все сложносочинённые ключи делаются через квадратные скобки. local mytable = {} othertable = { [mytable] = 1 } local foo = mytable othertable[foo] --> 1 othertable.foo --> nil, в данном случае foo это строка, как othertable["foo"] То же самое со всякими числами если тебе нужны дырки, сложносоставными (или даже многострочными) ключами и так далее.

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

xmake точно форк premake? Что-то не написано нигде. А вообще я немного негативно отношусь к китайскому софту, их проекты всегда выглядят так как будто они их чисто для себя пилят, инфа и ишьюсы на китайском и пользы для всего остального мира мало. Больше похоже на "мы выбросили а вы сами разбирайтесь" а не на opensource нормальный. У этого проекта хоть ридми на английском есть и то ладно.

xmake точно форк premake? Что-то не написано нигде. А вообще я немного негативно отношусь к китайскому софту, их проекты всегда выглядят так как будто они их чисто для себя пилят, инфа и ишьюсы на китайском и пользы для всего остального мира мало. Больше похоже на "мы выбросили а вы сами разбирайтесь" а не на opensource нормальный. У этого проекта хоть ридми на английском есть и то ладно.

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

Я правильно понимаю, что luasocket не умеет в unix-овские сокеты?

Возьму luv тогда

Luasocket про кроссплатформу.

Для кроссплатформенной многопоточности можно дёргать lanes или другие либы дающие то же самое. Для общения между разными, не связанными друг с другом процессами можно использовать обычный luasocket, делая запросы на localhost аналогично юникс-сокетам с всего лишь чуть меньшей скоростью обмена но кроссплатформенностью. Для подсоединения к уже реализованному кем-то приложению с юникс-сокетами — в любом случае понадобятся именно они, возьми что-то ещё, как раз вроде luv. Лично я советую использовать кроссплатформенные варианты везде где возможно, мало ли как что обернётся.

Для кроссплатформенной многопоточности можно дёргать lanes или другие либы дающие то же самое. Для общения между разными, не связанными друг с другом процессами можно использовать обычный luasocket, делая запросы на localhost аналогично юникс-сокетам с всего лишь чуть меньшей скоростью обмена но кроссплатформенностью. Для подсоединения к уже реализованному кем-то приложению с юникс-сокетами — в любом случае понадобятся именно они, возьми что-то ещё, как раз вроде luv. Лично я советую использовать кроссплатформенные варианты везде где возможно, мало ли как что обернётся.

Нету здесь кроссплатформы, т.к. приложение linux-only

Лады.

А есть пример luasocket с unix?

Нет, luasocket не умеет в unix, но можно общаться между процессами по TCP, с тем же результатом в большинстве случаев но с кроссплатформой. Перечитай.

Нет, luasocket не умеет в unix, но можно общаться между процессами по TCP, с тем же результатом в большинстве случаев но с кроссплатформой. Перечитай.

Увидел, и мне так не нужно

Для кроссплатформенной многопоточности можно дёргать lanes или другие либы дающие то же самое. Для общения между разными, не связанными друг с другом процессами можно использовать обычный luasocket, делая запросы на localhost аналогично юникс-сокетам с всего лишь чуть меньшей скоростью обмена но кроссплатформенностью. Для подсоединения к уже реализованному кем-то приложению с юникс-сокетами — в любом случае понадобятся именно они, возьми что-то ещё, как раз вроде luv. Лично я советую использовать кроссплатформенные варианты везде где возможно, мало ли как что обернётся.

Кстати, раз уж разговор об этом зашел. С чистыми luasocket и lua-lanes возможно сделать многопоточный хендлинг? Потому что мне приходилось свой бинарник luasocket собирать, сунув в метатаблицу функцию setfd, которой нет по дефолту. В итоге в одном потоке у меня работал accept(), как прилетал клиент - создавался новый поток и в него отправлялся client:getfd(), а уже внутри потока происходила магия по созданию dummy-юзердаты TCP сокета и присвоения ей полученного дескриптора.

Я что-то искал более удобное решение, но ничего не нашел.

Обычно делается не так. Создаются потоки, один висит в ацепте, как получил дескриптор, отдает его в очередь и кто свободен - забирает. Ибо создание потока, если мы о system thread, довольно тяжёлая задача

А недавно в линухи запилили фичу, что могут сами воркеры висеть в ацепте и если один схватил соединение, остальные не просыпаются. Раньше все посыпались

Но это надо включать

Ну а высший пилотаж создавать треды, в которых работа идёт через асинхронщину

А почему тогжа нельзя на С написать многопоточный listener и оркестратор? Запустить в каждом lvm и потом уже отдавать в конкретный поток в котором со старта крутится lvm?

Ну а высший пилотаж создавать треды, в которых работа идёт через асинхронщину

На ланесах вполне можно держать треды, в которых закорутиненные подпотоки. Правда, для полноценной реализации ещё нужна какая-нибудь либа асинхронного ввода-вывода, и запуск тредов с корутинами по событиям чтения/записи.

На ланесах вполне можно держать треды, в которых закорутиненные подпотоки. Правда, для полноценной реализации ещё нужна какая-нибудь либа асинхронного ввода-вывода, и запуск тредов с корутинами по событиям чтения/записи.

да, именно так, согласен

Конечный результат охренителен, инфа сотка.

Обычно делается не так. Создаются потоки, один висит в ацепте, как получил дескриптор, отдает его в очередь и кто свободен - забирает. Ибо создание потока, если мы о system thread, довольно тяжёлая задача

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

@kraftwerk28 @Snusmumriken @smertig @moteus писал неделю назад сюда по поводу передачи коннекшена к БД из с++ в Lua. видел ваши предложения, попробовал, но в итоге оказалось, что мою задачу нужно было решать вообще иначе (использовать динамическую lsqlite3 вместо статической). Но в любом случае спасибо большое за помощь.

А в чём принципиальная разница? У тебя там были баги какие-то? В целом, статика и динамика не должны иметь принципиальной разницы.

А в чём принципиальная разница? У тебя там были баги какие-то? В целом, статика и динамика не должны иметь принципиальной разницы.

Моя проблема заключалась в том, что у меня при закрытии коннекшена в Lua исчезал WAL файл базы данных SQLite. Как выяснилось, проблема была вызвана тем, что с++ использовал один инстанс sqlite3 библиотеки (версия 3.27.2, статическая), а LUA использовал другой инстанс sqlite3 библиотеки (версия 3.24.0 - из lsqlite3 версии 0.9.5, а именно lsqlite3complete, то есть статическая lsqlite3). Решение проблемы оказалось в том, чтобы использовать динамическую версию lsqlite3, которая линкуется динамически с libsqlite3.so, а также в с++ использовать динамическую версию sqlite3. Тем самым и LUA и с++ будут использовать один и тот же инстанс sqlite3.

Для меня было неочевидно, что во-первых у меня в Луа используется другая версия sqlite3 библиотеки, а во-вторых, что 2 разных инстанса библиотеки могут приводить к таким проблемам. Поэтому казалось, что решением будет общим коннекшеном пользоваться

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

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

А, окей. Я видимо не так понял предложение. Спасибо)

Ну, я на сишке когда сервер писал для игры, по интернетам рылся, искал, как лучше сделать. Не придумал ничего круче, кроме как при каждом удачном accept'e создавать структуру "Client" и в неё писать дескриптор сокета, ну а после вызвать pthread_create (или CreateThread, в зависимости от системы) и в поток передавать эту структуру. А поток уже делал с ней грязные делишки, принимая инфу от сокета и записывая её в структуру.

Обычно делается не так. Создаются потоки, один висит в ацепте, как получил дескриптор, отдает его в очередь и кто свободен - забирает. Ибо создание потока, если мы о system thread, довольно тяжёлая задача

А недавно в линухи запилили фичу, что могут сами воркеры висеть в ацепте и если один схватил соединение, остальные не просыпаются. Раньше все посыпались

Но это надо включать

Ну а высший пилотаж создавать треды, в которых работа идёт через асинхронщину

В итоге все сокеты получились блокирующими и не мешают друг-другу. Пришлось ещё, правда, костыль один навертеть, если клиент в вебе запускался, то соединение шло в вебсокетах, а не на сыром TCP, сделал в начале потока цикл из 10 шагов, который recv вызывает с флагом MSG_PEEK и ждёт "GET /", если дождался - делаем хендшейк вебсокетный и запускаем цикл получения сообщений, если не было "GET /", то как обычного клиента.

Ну, я на сишке когда сервер писал для игры, по интернетам рылся, искал, как лучше сделать. Не придумал ничего круче, кроме как при каждом удачном accept'e создавать структуру "Client" и в неё писать дескриптор сокета, ну а после вызвать pthread_create (или CreateThread, в зависимости от системы) и в поток передавать эту структуру. А поток уже делал с ней грязные делишки, принимая инфу от сокета и записывая её в структуру.

Это дичайше древняя технология, создавать тред под клиента. Первая попытка сделать так, чтобы "подсоединённый клиент не блокировал других клиентов". Правда, количество тредов обычно ограничивается цифрами 100/1000, иначе слишком много ресурсов начинает тратиться на переключение тредов и процесс становится ещё медленнее чем при однопоточке.

Это дичайше древняя технология, создавать тред под клиента. Первая попытка сделать так, чтобы "подсоединённый клиент не блокировал других клиентов". Правда, количество тредов обычно ограничивается цифрами 100/1000, иначе слишком много ресурсов начинает тратиться на переключение тредов и процесс становится ещё медленнее чем при однопоточке.

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

Так что в худшем случае будет 127 клиентов

Я думал переписать на select/poll, но не придумал, как лучше всего это сделать

А вот, собственно, и сам протокол. Тут даже динамического размера данных нет, везде статика https://wiki.vg/Classic_Protocol

Строки и те фиксированные по 64 байта.

На какие же извраты народ идёт, лишь бы Эрланг не учить.

Если мы говорим о игровом сервере с большим количеством клиентов, то тут уже udp стоит использовать, точнее rudp

На какие же извраты народ идёт, лишь бы Эрланг не учить.

Можно и его, но часть придется все равно делать на С, ибо математика не нем не шибко быстрая

Хых, писал rudp-протоколы, и это довольно жестяная жесть ) Как либа отлично заходит enet, благо она даже в steamworks используется (местные сетевые пакеты через стимовую апишку пересылаются enet'ом, и на нём можно накатать серверы которые будут связаны с игрулями пользующимися протоколами из стима)

Хых, писал rudp-протоколы, и это довольно жестяная жесть ) Как либа отлично заходит enet, благо она даже в steamworks используется (местные сетевые пакеты через стимовую апишку пересылаются enet'ом, и на нём можно накатать серверы которые будут связаны с игрулями пользующимися протоколами из стима)

Я помню, у меня даже что-то твое лежит, хотел добраться поизучать

Ну у меня там технология типа: Первый пакет с метаданными, и куском данных + фрейм из нескольких пакетов, А посылает его Б и ждёт ответочку, мол, какой последний последовательный пакет принят, начинает пересылать дальше фреймом из нескольких пакетов начиная с последнего последовательно принятого. Короткие пакеты отсылаются одним сообщением, что плюс.

Можно и его, но часть придется все равно делать на С, ибо математика не нем не шибко быстрая

Nif/port. Всяко проще, чем наоборот.

Nif/port. Всяко проще, чем наоборот.

Давай тогда сразу и игрушку на erlang'е пилить, чтобы стек библиотек/технологий был одинаковым )))

Если мы говорим о игровом сервере с большим количеством клиентов, то тут уже udp стоит использовать, точнее rudp

Вообще да, но игра эта раньше вообще только жава апплетом была и стендалоном не запускалась вообще, в сетевом плане там ужасно всё)))

Вообще да, но игра эта раньше вообще только жава апплетом была и стендалоном не запускалась вообще, в сетевом плане там ужасно всё)))

Ну есть куда расти )

А вот enet - классная штука, да. Очень удобный.

Если мы говорим о игровом сервере с большим количеством клиентов, то тут уже udp стоит использовать, точнее rudp

На самом деле, можно сделать гораздо проще и тупее использовать TCP и UDP одновременно. Открываешь на сервере один и тот же порт для TCP и UDP, по одному посылаешь длинные данные которые прям кровь из носу надо доставить, по второму — быстро устаревающую фигню. Всё.

Давай тогда сразу и игрушку на erlang'е пилить, чтобы стек библиотек/технологий был одинаковым )))

Для бекенда мой первый выбор, да. А есть и вот такое: http://www.erlang-factory.com/upload/presentations/395/ErlangandFirst-PersonShooters.pdf

Для бекенда мой первый выбор, да. А есть и вот такое: http://www.erlang-factory.com/upload/presentations/395/ErlangandFirst-PersonShooters.pdf

Давай мы не будем привязываться к конкретным технологиям. Это плохо. Я гарантирую. Алгоритм/протокол > технология/язык.

На самом деле, можно сделать гораздо проще и тупее использовать TCP и UDP одновременно. Открываешь на сервере один и тот же порт для TCP и UDP, по одному посылаешь длинные данные которые прям кровь из носу надо доставить, по второму — быстро устаревающую фигню. Всё.

Так и делают, но тут какой момент, если тсп канал забивается, то udp сетевым стеком откладывается, пока он не разберётся с тсп

Во всяком случае читал о таких приколах

Опять бекендеры набежали. А прикидывались приличными людьми, мол, луа любим.

Давай мы не будем привязываться к конкретным технологиям. Это плохо. Я гарантирую. Алгоритм/протокол > технология/язык.

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

Так и делают, но тут какой момент, если тсп канал забивается, то udp сетевым стеком откладывается, пока он не разберётся с тсп

Ох, сколько нужно говна чтобы забить TCP-канал? Тут были проблемы у одного (Тони по моему, или Trash++), у которых "канал забивался" потому что они за один кадр принимали только одно сообщение. Чтобы забить типовой TCP-канал, нужно прям о-о-о-очень много говна, которое просто не пропустит провайдер из-за перегрузки сети.

Опять бекендеры набежали. А прикидывались приличными людьми, мол, луа любим.

Ох, сколько нужно говна чтобы забить TCP-канал? Тут были проблемы у одного (Тони по моему, или Trash++), у которых "канал забивался" потому что они за один кадр принимали только одно сообщение. Чтобы забить типовой TCP-канал, нужно прям о-о-о-очень много говна, которое просто не пропустит провайдер из-за перегрузки сети.

50к игровых клиентов?)))

50к игровых клиентов?)))

Без проблем. Уменьшаешь трафик, заставляешь эти 50к клиентов посылать минимальные сообщения, объединяешь отдельные короткие сообщения в один 1кб-пакет. Для типовой игры нужно очень мало трафика.

Особенно если у тебя нет локаций где больше сотни клиентов, и каждому надо переслать данные о каждом (решается игровыми слоями).

Тут вопросы, что раньше забьется, клиентский канал или серверный.

Карочи, 50к коннектов решаются: 1. Кластером серверов 2. Балансировкой 3. Слоями, на которые распределяются клиенты (инстансы) И это совсем не проблема TCP или UDP, если грамотно написать с учётом игровой специфики — всё будет ок.

Небольшая история, сервер линейки легко держал больше 5к, но когда шла осада, много людей было в одном месте и сеть у клиентов была забита, хотя сервер на 20%

Вот если ты сделаешь одну игровую комнату на все 50к клиентов — с этим не справится ни один суперкомпьютер, тупо потому что всем клиентам надо отсылать данные о каждом. Там объём трафика растёт по экспоненте в зависимости от количества игроков в одном месте.

Ну есть куда расти )

Было бы, если бы игра развивалась дальше. В 11-12 году эту версию сделали архивной сами разработчики, а те, кто не пожелал от неё отказываться, написали свой порт клиента на Си, ну и сервер на шарпе, оригинальный протокол никак не трогали. Разве что расширение для него написали. У хендшейк пакета есть зарезервированный байт, который оригинальным клиентом никак не юзается, а клиент, который поддерживает расширение протокола устанавливает его а 0x42. В общем там костыль на костыле и костылём погоняет.

Было бы, если бы игра развивалась дальше. В 11-12 году эту версию сделали архивной сами разработчики, а те, кто не пожелал от неё отказываться, написали свой порт клиента на Си, ну и сервер на шарпе, оригинальный протокол никак не трогали. Разве что расширение для него написали. У хендшейк пакета есть зарезервированный байт, который оригинальным клиентом никак не юзается, а клиент, который поддерживает расширение протокола устанавливает его а 0x42. В общем там костыль на костыле и костылём погоняет.

Ну так же было с линейкой и ВОВом )

Небольшая история, сервер линейки легко держал больше 5к, но когда шла осада, много людей было в одном месте и сеть у клиентов была забита, хотя сервер на 20%

Вот в этом случае, кстати, можно смело врубать сглаживание и обновлять клиентов по частям: за четверть секунды один клиент получил данные о половине игроков, за другую четверть — о другой половине. Да, появляется некоторый лаг, но на него насрать, если хорошо сглажено. И так можно растягивать в зависимости от количества. Чем больше народа тем больше лаг, но компенсация это пофиксит. Эвристика показывает что хорошо сглаженный лаг до секунды — норм.

Ну так же было с линейкой и ВОВом )

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

Вот в этом случае, кстати, можно смело врубать сглаживание и обновлять клиентов по частям: за четверть секунды один клиент получил данные о половине игроков, за другую четверть — о другой половине. Да, появляется некоторый лаг, но на него насрать, если хорошо сглажено. И так можно растягивать в зависимости от количества. Чем больше народа тем больше лаг, но компенсация это пофиксит. Эвристика показывает что хорошо сглаженный лаг до секунды — норм.

Ну вариант, да. Но обычно на архитектуру игрового сервера все забивают))) Ну либо я чего-то не понимаю и для fps сервера 64 человека это максимум без лагов

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

Вот только написал)

Ну вариант, да. Но обычно на архитектуру игрового сервера все забивают))) Ну либо я чего-то не понимаю и для fps сервера 64 человека это максимум без лагов

У FPS, в отличии от какой-нибудь РПГ, есть несколько неприятных особенностей: 1. Все действия крайне быстры и не откатываемы (у рпг можно вернуть задетого или как бы убитого на клиенте персонажа, если сервер понял что последние действия были нелегитимными из-за лагокомпенсации, а у FPS — нет); 2. Из-за особенностей быстрого перемещения и видимости, нельзя сглаживать слишком сильно, например игрок шёл к краю укрытия, а другой клиент одного из игроков на другом конце карты досглаживался что идущий к краю таки вылез из укрытия, чего на самом деле не произошло, но он уже знает что там будет челик.

У FPS, в отличии от какой-нибудь РПГ, есть несколько неприятных особенностей: 1. Все действия крайне быстры и не откатываемы (у рпг можно вернуть задетого или как бы убитого на клиенте персонажа, если сервер понял что последние действия были нелегитимными из-за лагокомпенсации, а у FPS — нет); 2. Из-за особенностей быстрого перемещения и видимости, нельзя сглаживать слишком сильно, например игрок шёл к краю укрытия, а другой клиент одного из игроков на другом конце карты досглаживался что идущий к краю таки вылез из укрытия, чего на самом деле не произошло, но он уже знает что там будет челик.

Досглаживался, интересное определение, надо запомнить😂

Ну и FPS тупо пересылают гораздо больше трафика.

У FPS, в отличии от какой-нибудь РПГ, есть несколько неприятных особенностей: 1. Все действия крайне быстры и не откатываемы (у рпг можно вернуть задетого или как бы убитого на клиенте персонажа, если сервер понял что последние действия были нелегитимными из-за лагокомпенсации, а у FPS — нет); 2. Из-за особенностей быстрого перемещения и видимости, нельзя сглаживать слишком сильно, например игрок шёл к краю укрытия, а другой клиент одного из игроков на другом конце карты досглаживался что идущий к краю таки вылез из укрытия, чего на самом деле не произошло, но он уже знает что там будет челик.

Тут ещё влияет пинг сильно, сервер надо поближе к народу ставить

У РПГ оно не настолько важно, особенно если куча вещей требуют времени каста, это автоматом растягивает трафик и ограничивает количество действий в секунду. Алсо в этом помогает ГКД.