Евгений Шатунов, Проблема очень простая - как поступает средний программист. Он берет и посылает в TCP и в UDP сегменты одинакового размера, после чего смотрит время отклика - и наблюдает, что с ростом числа отправленных сегментов в секунду, TCP начинает отставать, причем при большом расстоянии между хостами в плане географии, остает драматически (RTT умножается на три, а то и на пять)
После этого остается выбор - взять UDP, который очевидно, работает здесь и сейчас, или заниматься мифическими действиями:
задержку от буферизации TCP можно нивелировать техническими приемами и настройками протокола
которые сегодня может быть сработают, завтра - не сработают. Или у разработчика работает - а у клиента - нет, потому что у него провайдер, который использует шейпер трафика, который в свою очередь, осуществаляет интересные манипуляции с TCP Window, что и приводит к буферизации.
Разумеется, если у вас есть литература или статьи, которые объективно показывают, как настроить TCP, чтобы RTT не умножалось в разы при изменении размера посылаемого пакета, я с радостью ознакомлюсь.
Талян, дополню себя тем, что идеальный профиль нагрузки для TCP, это когда в сокет нечасто записывают сразу огромный блок, после чего ОС начинает его отсылать пакетами размером с MSS c максимальной установившейся скоростью
В то же время, профиль, формируемый игрой - это отправка 5-15 мелких блоков каждую секунду, что сразу сталкивается с разными алгоритмами, препятствующими появлению флуда - вроде алгоритма Нейгла.
Талян, потому что пакеты UDP быстрее проскакивают через маршрутизаторы, не встречая на своем пути интересные алгоритмы управления потоком, которые применяются к пакетам TCP
Очевидно, что если речь идет о проскальзывании гусеницы или о каком-то другом физическом явлении, кроме программных средств, нужны какие-то сенсоры для обратной связи.
Там у вас будет framerate - количество фреймов с данными в секунду. Вот берете столько фреймов, сколько у вас в секунде, склеиваете их в массив и считаете RMS
Учтите, что того, чтобы перевести полученные единицы измерения (там что-то типа вольт * попугай), где попугай = 2 ^ -( разрядность АЦП - 2), в реальные единицы громкости (децибелл * вольт) надо еще взять логарифм по основанию 10.
Drno, Все зависит от интересных деталей - например, кому-то нужен пульт с физическими кнопками, который можно держать в руках (например, это оборудование для театральной постановки), кому-то достаточно примитивного гуя на планшете. Без этих интересных подробностей ответ будет похож на книгу, причем вопрошающему их нее нужно будет процента три.
gth-other, для этого есть тупой, стандартный, и аппаратно ускорееный на Интеле способ - считать CRC32 каждого файла и класть рядом. Хотите быть злее - считайте SHA256 (причем раз так 10000, чтобы брутфорсеру было весело).
Первый ответ, который приходит ко мне в голову, когда я вижу криптографический велосипед - он опасен, и безопасен одновременно. Опасен, потому что про него никто не знает - а значит, никто не пользуется и эксперты в нем не ищут дыры. Ну и безопасен он по этой же причине.
Денис _______________, так я и не говорю, что вы лжете - я понимаю, что в некоторых условиях трюк с пробросом может сработать. Сейчас отредактирую свой ответ.
Tylen, нет, потому что это как раз то, что вам делать запрещено (копировать строку, а потом переворачивать копию) + дополнительные ненужные действия в виде удаления восклицательный знаков, пробелов и запятых.
Я не особо люблю развлечения в формате пойди туда, не знаю куда. Это задание с собеседования? Вам дали дамп и типа - го, объясните что тут не так? Или у вас есть еще жалобы пользователя на что-то?
Самый простой метод решения таких проблем - иметь эталонный дамп и сравнивать с ним.
Михаил, ну вот смотрите, L в SOLID - это принцип подстановки Лисков, сугубо теоретическая идея (Опубликованная в статье Behavioral Subtyping Using Invariants and Constraints). Обратите внимание на слова Константы и Инварианты - это прямо bread and butter процесса абстрагирования.
Как и весь остальной SOLID и DRY по которым, например строится математика как формально-логическая структура из аксиом, теорем, определений и ссылок. Обратите внимание, что я указал только эти две аббревиатуры, MVC, MVP - это уже гораздо ближе к рутинной практике.
Раз это абстрактные вещи, не привязанные к каким-то языкам программирования или технологическим решениям - это фундаментальная CS.
После этого остается выбор - взять UDP, который очевидно, работает здесь и сейчас, или заниматься мифическими действиями:
которые сегодня может быть сработают, завтра - не сработают. Или у разработчика работает - а у клиента - нет, потому что у него провайдер, который использует шейпер трафика, который в свою очередь, осуществаляет интересные манипуляции с TCP Window, что и приводит к буферизации.
Разумеется, если у вас есть литература или статьи, которые объективно показывают, как настроить TCP, чтобы RTT не умножалось в разы при изменении размера посылаемого пакета, я с радостью ознакомлюсь.