PantyDev, попробуй изобрести велосипед. Мне кажется это задача в которой нет идеального алгоритма.
Тут надо работать аккуратно чтоб
1) Не DDOS ить сервер и клиентов ненужными сетевыми событями
2) Предоставлять точную картину мира интерполированием известных координат объектов в прошлом.
Мне эта задача нравится тем что ... она как-бы прилижается к некоторым задачам физики в космосе.
Мы как-бы не можем видеть актуальную картину мира. И каждый участник сетевой игры видит
исторический снимок.
Ну я себе вижу такой сценарий. Поставь OpenVPN клиент на сервер где работает PHP.
Разберись какие порты открыты в destination. Если это sftp то там допустим будет порт 22.
Далее попробуй просто физически находясь на сервере через консоль sftp подключиться
к destination. Вот. Ну если прокатит то вот сделай так тут советуют
Vadik7777, сокетное соединение везде выглядит одинаково. Во всех языках и системах.
Но до того как это соединение создавать нужно знать IP адрес или имя в системе имен этой VPN.
imsetup, ну для проектов нужно содержание. Идея какая-то. А то так любой школьник зайдет
например в spring initializer и накликает мышкой там тыщи технологий. И получит шаблон проекта.
Да есть такое в Java. Понторезка такая. У вас в Go еще нету наверное. Ну оно и хорошо.
Мне нравится когда лаконично.
И знаешь как мудрые говорят. Хорошо там где нечего отнять
Владимир Коротенко, любой виндузятник может сегодня устанавливать подмножество утилит Linux из менеджера пакетов chokolatey. Поэтому awk/gawk сегодня уже не та цель ради которой я-бы пересаживал кого-то.
Но смысл в этом вобщем-то есть. Там и MySQL легче поднимать :)
Вообще если глубоко погружаться в спецификацию CSV то в 1 ячейку можно вставить другой
CSV файл с сохранением семантики данных. Все легально и позволено. Но уже работать авк-ками
и греп-ами будет сложнее.
Eugene-Usachev, выше ты пишешь что коллизии неизбежны. Да. Они неизбежны по свойству множеств.
Множество значений ключа обычно (как правило) мощнее чем множество значений хеша. Принцип Дирихле! Это вообще
база хеш-таблиц. Если-бы этой базы не было - то мы ушли-бы от функции расстановки к прямому доступу
к таблице как к массиву. С другой стороны если у тебя ключ - i32 - (4 млрд значений) то выдели себе
массив на 4 млрд 4х байтных чисел (указателей?) (это будет 16 Г) и пользуся! Прямой доступ. Ключ == индекс.
Красота.
И будет тако себе будерброд и хеша и тела ключа. Но это на самом деле tradeoff. Перенос проблемы
из области вычислений в мемоизацию. Это надо прикинуть хорошенько не ударит ли по памяти например.
Тебе хеш нужен дважды. Первый раз при вставке ключа в хеш-таблицу.
И второй раз при поиске. И это неизбежно потому что дистанция между
этими событиями - бесконечно большая во времени и хранить эти временные
штуки негде.
