которые на двигле source короче

по UDP к серверу подключается

Ааа количество просто?

А на чем накатал? На луа?

да

это ники и очки игроков

Здорово

там ещё передаётся время, которое они наиграли и количество игроков

у source query вообще не сложный протокол

и документация хорошая

поставил себе задачу: справиться без ffi, но получилось очень костыльно

потому что я luasocket в последнее время недолюбливаю

А зачем тут ффи?

для того чтобы напрямую к функциям сокета обращаться

а не через прослойку в виде luasocket

Из глибц

Понятно

Но это чревато наверное

Я не знаю как ффи с глибц работает

ffi нормально со всем работает

я уже писал сокетовую либу

только для TCP

которая совместима и с POSIX-подобными и с окнами

Через ффи писал?

Да

Из-за того, что я не использовал в скрипте квери ffi код совсем чуть-чуть страшный

да и float читать пока нечем

можно было бы чуть-чуть по-другому всё организовать, но не стоит забывать: я не спал нормально 2 дня :D

Вот то, что я для ffi накатал https://github.com/igor725/LuaClassic/blob/master/lua/network/socket.lua

Через ффи писал?

Спасибо

Тут всё тоже не очень хорошо по чистоте кода

у меня там ещё библиотека websocket'ов валяется маленькая в той же папке

работает вмест с этими сокетами только

мою библу, думаю будет не очень удобно использовать в каких-либо проектах, потому что она под определённый писалась, чтобы её было удобно использовать именно там

Ну можно вебсокеты перепилить на луасокет

И использовать отдельно

под luasocket уже есть библы вебсокетов

Думаю будет востребовано

но они все неудобны были для меня

Ааа пончл

одна там вообще с двумя зависимостями и недоделана

ей там copas был нужен и ещё что-то

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

Его реализация, кстати, в разы удобнее моей https://github.com/CapsAdmin/luajitsocket/blob/master/ljsocket.lua

Какой же ты засранец, затаил обидушку а теперь выпендриваешься ))

Я вчера спал, добреутро

А на тему tcp-прокси — мб можно подумать на тему того чтобы накатать чистую проксю, на луасокетах или ещё чём-то. Должно быть не очень сложно, но надо чуть-чуть подумать чтобы сделать асинхронно и крутенько.

Но с чтением есть одна фигнюшка. TCP — потоковый протокол. Способы разделения сообщений у каждого приложенческого протокола свои, а иногда их и нет вовсе. А для того чтобы подменять сообщения — прокси должна знать, по какому приложенческому протоколу в данный момент передают данные, сепарировать отдельные сообщения, препарировать их и выдавать на другую сторону.

ну вот, в этом-то и проблема

из-за потоковости протокола

не, сами сообщения, которые надо подменять, я понимаю

сообщения в виде json

Хех, а как они отделяются друг от друга?

\n

ну это еще можно перепроверить будет, просто я не могу даже поснифать толком )

тока я читаю сообщение, оно уже не попадает к proxy_pass и я не могу выдать нужный ответ

Ага. Значит катаешь на луях tcp-приёмник, который принимает в себя всякие json'ы через \n-разделитель, правит их и передаёт куда-нибудь ещё, и в обратку.

А если там HTTPS или аналог (tls какой-нить), то всё плохо ))

ну принимать это я могу

т.е. все отлично принимается, сообщение читается, там чистый жсон

а далее я должен открыть сокет с источником и передать это ему, получить ответ, выдать клиенту

я вообще правильно мыслю?

и все это в рамках stream nginx

и луа там этот будет

https://github.com/openresty/stream-lua-nginx-module

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

ну а почему нет, там как бы json ответ, который скажем говорит, что у тебя версия 3, а ты говоришь - а у меня версия 2

а, ну да, я не нашел способа в нгинксе фильтровать

но принципиально фильтровать думаю можно

А кто принимает все эти сообщеньки с жсонами?

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

ну есть 2 узла A и B

один из них отсылает, другой принимает - они могут сами с собой работать

я хочу между ними встать и фильтровать

и разруливать, в какой-то момент вместо узла B перекинуть D, если это выгоднее и т.д.

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

т.е такай система маршрутизации, но не просто менять прокси сорс, а менять еще и сами сообщения

потому что скажем узел D не поддерживает напрямую узел A