rPman

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

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

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

И пофиг с чем работать, ухо, нос, задница,

Без какой либо дополнительной информации у вас есть только один метод - вручную выделить данные, создав таким образом обучающую выборку для нейронной сети, и обучить ее на их основе.

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

webrtc
необычный механизм, но определить куда и откуда уходят управляющие запросы и информация будет практически невозможно (если она будет уходить к каждому клиенту в сети и дальше p2p)

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

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

В вашем случае это не точки а связный двунаправленный граф, где вершины - города, а ветви - дороги. Соответственно вы ваши загружаемые точки должны привести к этому же вижу - подграфу, сначала поиском точек (вычисляя расстояние между искомой точкой и точкой города, определив минимальное).

Если это критично, так же можете попытаться искать попадание точек на дороги (но это в общем случае невозможно, дороги ведь в реальности не прямые, а в базе у вас только точки городов).

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

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

char buf[256];
fscanf(stdin,"%255[\n]",buf);

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

в крон задании сохраняйте pid процесса в файл (запускайте через & и сразу берите pid из переменной $!), а соответственно перед этим, убиваете процесс с pid из этого файла (если он есть).

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

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

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

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

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

p.s. массовые рассылки от проекта или партнеров (не кривитесь, все это хотят делать) не делайте обычными чатами, а то будут получаться странные выверты с мегадублированием информации и огромной нагрузкой в момент их проведения, пусть это будет отдельная сущность (остальное разрулите в интерфейсе). С другой стороны, если вам нужна обратная связь, в тот момент, когда пользователь вдруг решает ответить в такой недочат - конвертировать его в обычный.

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

Если вдруг что то получится (зависит от ваших доходов, если они незаметные на фоне оборотов правообладателя то у вас нет шансов), то проблема легализации - уже будет не ваша.

p.s. не советую работать лично, пусть риски недовольства правообладателя, если не договоритесь, берет кто то другой

На текущий момент для веб лучшие решения крутятся вокруг webrtc, народ пилит обычно сервера на nodejs.
Первый же пример из гугла webrtc audio streaming:
https://github.com/enjikaka/webrtc-audio-stream

m-k-m

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

p.s. если вам нужны запросы по элементам адреса, не городите велосипед, возьмите КЛАДР. настоятельно рекомендую не дублировать базу у себя а использовать рядом лежащую, кажется там есть готовый api для этого, а вы пользуйтесь его идентификатором, но помните, там не все адреса (это может создать миллион проблем, из-за которых люди дублируют кладр у себя в базе, но тогда начинается геморой с ее обновлениями, можете продублировать структуру но данные первично загружайте из кладр)

p.p.s. https://habr.com/post/214945/
https://habr.com/post/140378/

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

Таким пользуются и вебсервисы, это просто для реализации.

Например база данных - на запрос единицы данных ставьте лимиты времени (лучше на некоторое их количество), таким образом чтобы за 24 часа всю базу просканировать автоматическими системами не получилось бы.

В универсальном случае, как ни странно, на текущий момент такой функцией являются нейронные сети, на хабре была статья про исследователей, эксперементирующих с восстановлением видео с использованием мизерной функции (нейронной сети, причем там получались считанные килобайты на все видео).
https://habr.com/post/372337/

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

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

У разных виртуалок свои сетевые устройства, объедините их в бридж (в win это зовется сетевой мост), можно объединить вместе с физической сетевой картой, тогда с точки зрения сети эти виртуалки станут просто отдельными устройствам в локальной сети, и ваш dhcp сервер (роутер) выдаст им каждому свой адрес (и будет работать NAT если используется).

Каждый час - свой атрибут в таблице (т.е. 24-атрибута, а их значения в таблице - цены), ведь в запросах эти данные будут подставляться конкретным значением, а значит это можно делать генерируя сам запрос (это не повлияет на скорость его исполнения), зато не будет перегруженной структуры, лишних индексов и оверхеда на работу с ними = плюс к скорости и простоте разработки.

Во первых, вопрос, у вас нет смартфона android? Вы прописывали свой аккаунт на нем? Вы точно говорите правду? У народа по 3-5 аккаунтов, просто так созданных, может быть и вы создали и забыли, а спамеры пароль расковыряли и пользуются? А аккаунты связаны с вашим поведением, ip, или даже в одном браузере (куки) логинились.

Исходя из этого, если вы разработчик, создавайте для своих приложений отдельный аккаунт и 'прокачивайте' его максимально независимо (отдельный ip, специально купленный, никогда не выходить со своего основного аккаунта, держать специальный профиль браузера для работы, и мобильное устройство тоже отдельное приобрести (самый сложный вопрос)... по крайней мере главный ваш аккаунт не будет испачкан.

p.s. Ситуация с гуглом ужасна и отвратительна идеологически, и дальше будет хуже. Мы (не только программисты) зависимы от этого монополиста, на столько сильно что это может влиять на нашу жизнь негативным образом и плохой abuse-support этому только способствует.

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

По завершению у вас метод вернет список областей, являющихся белыми.

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

Этот алгоритм значительно шустрее, но работает только с замкнутыми областями и относительно равномерным белым цветом, т.е. если там будут разводы и переходы, будет заметно сложнее)