самым логичным решением будет перевести слово на язык, использующий только латинский алфавит
или просто переключить раскладку, тогда «баклажан» превратится не в «aubergine» а в ",frkf;fy"
одним из способов сочинять пароли, которые мне известны — брать известный бренд и разделять его химической формулой типа Mercedes + HN03 = MerHN03cedes
в *nix-овом мире принято иметь один инструмент для одной задачи, например, recovery record с заданным колчичеством избыточной информацией к 7z архивам можно добавлять с помощью другого инструмента — par2 en.wikipedia.org/wiki/Par2
с трукриптом можно в принципе отдавать и компьютер, хорошая штука — шифрование системный разделов, шифрование с двойным дном… правда от терморектальных криптоаналитиков все равно не спасет.
суть тормозов TCP как раз и заключается в ожидании подтверждения получения пакетов и повторной их пересылке
Если теряется, скажем, 75% пакетов, то скорость падает катастрофически. В случае UDP — у нас всё время есть чем занять канал! Даже если будет теряться 90% пакетов — мы выберем всю пропускную способность канала и скачаем весь файл (хотя для этого нам придётся послать в 10 раз больше данных чем размер файла).
Данные не берутся ниоткуда и нам все равно нужно будет их повторно запросить и повторно получить в случае, если мы хотим получить файл. Если в случае с потоковым видео мы просто забываем про бракованные кадры, и не нагружаем сеть повторной пересылкой данных, в чем и состоит выигрышь от использвания UDP, то в случае с файлом — переспрашивать таки придется и выгоды от использования UDP нет.
Поправьте меня, если я ошибаюсь, но пересылая без толку 10 раз пакет по UDP и видя скорость приблизительно равную пропускной способности канала мы и получаем в результате ту же самую эффективную скорость (количество правильно доставленных пакетов: затраченное время) как и в случае использования TCP.
да, это кажется разумным — пересылать не весь битый пакет, а только запись для восстановления.
если пакет не удалось восстановить с помощью этой записи — тогда уже пересылать весь пакет заново.
Контролировать целостность можно на каком угодно уровне — суть в другом. Допустим после проверки целостности на уровне приложения стало понятно, что файл принят неверно и в нем есть части с ошибками. Что делать — вариантов два.
1) давайте еще раз качнем битые фрагменты.
в этом случае у нас не будет выигрыша от использования UDP.
2) давайте добавлять такую избыточную информацию в пакеты, чтобы она не только проверяла целостность, но и позволяла восстановить битые куски. (а-ля rar recovery record или par2)
Но тогда канал будет загружен еще больше, чем в случае с простым подтверждение о приеме отдельного пакета, как в TCP.
Ситуация недостаточно редкая, чтобы ею пренебрегать при передаче файлов.
Это в случае с голосом и видео кадрами можно плюнуть на кривой фрейм и показывать следующий, поэтому и переспрашивать не надо, и второй раз битый фрейм отправлять незачем.
Насколько я знаю, слишком много вычислительных ресурсов должно быть задействовано, чтобы рыться внутри ip пакета и проверять байтики внутри payload-а. Теоретически и алгоритмически сделать это нетрудно, но железяки должны быть специальные с NPU процессорами всякими.
Насколько я успел понять, это нечто вроде объединения, которое имеет свою целевую аудиторию (обычно ориентированную на какой-то жанр) и может распространять или предоставлять доступ к вашей музыке.
или просто переключить раскладку, тогда «баклажан» превратится не в «aubergine» а в ",frkf;fy"
одним из способов сочинять пароли, которые мне известны — брать известный бренд и разделять его химической формулой типа Mercedes + HN03 = MerHN03cedes
netstat -nap |grep [port_number]
суть тормозов TCP как раз и заключается в ожидании подтверждения получения пакетов и повторной их пересылке
Данные не берутся ниоткуда и нам все равно нужно будет их повторно запросить и повторно получить в случае, если мы хотим получить файл. Если в случае с потоковым видео мы просто забываем про бракованные кадры, и не нагружаем сеть повторной пересылкой данных, в чем и состоит выигрышь от использвания UDP, то в случае с файлом — переспрашивать таки придется и выгоды от использования UDP нет.
Поправьте меня, если я ошибаюсь, но пересылая без толку 10 раз пакет по UDP и видя скорость приблизительно равную пропускной способности канала мы и получаем в результате ту же самую эффективную скорость (количество правильно доставленных пакетов: затраченное время) как и в случае использования TCP.
если пакет не удалось восстановить с помощью этой записи — тогда уже пересылать весь пакет заново.
1) давайте еще раз качнем битые фрагменты.
в этом случае у нас не будет выигрыша от использования UDP.
2) давайте добавлять такую избыточную информацию в пакеты, чтобы она не только проверяла целостность, но и позволяла восстановить битые куски. (а-ля rar recovery record или par2)
Но тогда канал будет загружен еще больше, чем в случае с простым подтверждение о приеме отдельного пакета, как в TCP.
Это в случае с голосом и видео кадрами можно плюнуть на кривой фрейм и показывать следующий, поэтому и переспрашивать не надо, и второй раз битый фрейм отправлять незачем.
В смысле какой именно способ по-Вашему может иметь меньшие накладные расходы, чем уведомление о получении а-ля TCP.
Речь идет именно о той ситуации, когда клиент попросил переслать пакет повторно.
В случае, если одни и те же пакеты нужно будет отправлять по несколько раз — выигрыша от UDP по сравнению с TCP не будет.
DHT вроде как использовал UDP протокол
по крайней мере эти стандарты задумывались чтобы стало возможным отличать аудио и видео трафик от всего остального
правда оно не будет спасать, если файлообменная софтина будет тоже тегать свой трафик как аудио
en.wikipedia.org/wiki/Netlabel
Насколько я успел понять, это нечто вроде объединения, которое имеет свою целевую аудиторию (обычно ориентированную на какой-то жанр) и может распространять или предоставлять доступ к вашей музыке.
Cписок нет лейблов:
www.phlow.de/netlabels/index.php/Main_Page
Может читателя, а не автора?
Bли тогда «попытке автора...».