Для дачи взятки должностному лицу — нужно должностное лицо для начала. Неправомерный доступ к данным тут вообще неприменим. Поэтому, пока не вижу причины считать такой эксперимент незаконным.
Что же касается «а вдруг меня за это арестуют и будут судить, а там суд мне может нарисовать что-нибудь страшное» — так мне могут наркотики еще например подкинуть или кирпич на голову упасть — что теперь, на улицу не ходить?
Тогда давайте не будем теоретизировать. Я хочу например «получить детализацию за деньги». Пока эта детализация моя — не вижу в этой затее ничего незаконного независимо от того, в каком странном месте я её запросил (например, описанный в статье чатик — похоже то ещё странное место). Если вы можете рассказать как с юридической точки зрения мне можно вменять дачу взятки должностному лицу за это действие — буду вам благодарен.
Я думаю для начала что шанс, что кто-то из этих продавцов или покупателей окажется в суде — ничтожно мал. По причинам похожим на озвученные вами. Но за вариант про взятку — спасибо, на всякий случай учту.
Злоупотребляю служебным положением тоже не я, остается только взятка. Боюсь, тут тоже может быть сложно натянуть, особенно, если я данные по факту получил, они мои и я задокументировал весь процесс.
Нет, закону как раз не пофигу. В отличии от чужих ПД, в отношении своих я имею право решить, кому я разрешаю или не разрешаю их обрабатывать. Отсюда и вопрос.
Я всерьез задумываюсь о проведении такого эксперимента со своими данными (а именно — купить лично мои данные в даркнете). Почему вы считаете, что данные действия могут быть незаконными?
Ну, мне запомнились потери пакетов в диапазоне 30-50% на 64-байтных пингах. Сейчас, думаю, там так же или чуть хуже
Я сравниваю реальное использование внутренней разработки
Если у вас заранее известны особенности канала — понятное дело, заточенное под него решение будет работать лучше. То, о чем я пишу, я имею в виду в контексте глобальных сетей (плюс, желательно предусмотреть, чтобы толпа таких клиентов в одной локации не положила сеть лавиной ретрансмитов если вдруг аплинк на минуту пропадет)
Касательно очередности — да, согласен. Но тут имхо зависит от решаемой задачи. Лично я в контексте мессенжера предпочитаю подождать, пока соединение переподнимется и мне дойдут все сообщения, чем гадать, не потерялась ли часть смысла по пути. Если от этого отказаться — очевидно, UDP начинает подходить больше. И да, это именно то, что я имею в виду, когда говорю про аккуратное управление сессиями — то есть выставление таймаутов и переинициализация соединения, если оно залипло, если позволяет платформа — корректная установка опций сокета.
Разумеется, всё это я говорю в контексте коротких текстовых сообщений, если в ту же сессию полетят котики — разговор будет другой
Вы напрасно заняли агрессивную позицию. На самом деле вопрос интересный и простого ответа (в том числе, как у вас в статье) тут быть не может.
Вы сравниваете теоретический мессенджер на базе UDP с современными реальными на базе TCP и делаете достаточно жирное допущение о том, что проблемы современных мессенджеров связаны с TCP. Я говорю о том, что при разработке реального мессенджера с конкретным набором требований (шифрование, аутентификация, медиаконтент, подтверждения) — может оказаться, что не такой уж большой выигрыш дает UDP. Да, концепт без шифрования и прочих рюшек на UDP скорее всего выиграет, но не будет жизнеспособен в реальных условиях.
Я считаю, что проблемы современных мессенджеров не в том, что они используют TCP, а в том, сколько ещё уровней (часто избыточных) они используют поверх него.
Косвенно, это подтверждает мой опыт использования IRC, ICQ и Jabber через ранний GPRS — проблемнее всего тогда у меня был Jabber, и если взглянуть на его протокол — он самый избыточный. Позднее, когда компрессия стала распространенным явлением, вся тройка более-менее сравнялась и далее их юзабилити ограничивалось только глюками и особенностями конкретного протокола.
Кроме того, в общем, уже существуют протоколы, которые по крайней мере в теории поддерживают все три транспорта и используют более подходящее управление сессиями (MTProto). И да, оно лучше, но я бы не сказал, что на столько же лучше на сколько сложнее такая полная реализация.
Ну право же, SYN-ACKSYN-ACK это три очень маленьких пакета. Да, это занимает время, но это не так страшно, как установка TLS сессии и аутентификация поверх — вот с этим действительно надо бороться, а тут что по UDP что по TCP overhead будет примерно одинаковым
Проблема с приоритезацией решается просто — двумя независимыми сессиями. TCP, на самом деле, гарантирует только порядок и целостность и больше никакой магии не делает, и, в общем-то, это первое, что нужно будет придумать своё, если от него отказываться. Следующий «ой» будет на больших сообщениях, тех же картинках — их нужно будет склеивать. Это всё только на бумаге выглядит просто и без проблем — в реальных условиях будет немало сюрпризов.
В противовес этому, в варианте с TCP нужно просто написать нормальный менеджмент сессий. Но его для UDP какой-то тоже придется делать, хоть и попроще.
Справедливости ради, у TCP есть другая неявная проблема — особенности реализации под каждую ОС, например, разные таймауты по-умолчанию — но это можно и нужно решать менеджментом сессий.
В общем, если задачу ограничить как «доставить короткое сообщение немедленно и без шифрования» — UDP подойдёт. Если вы всё-таки хотите полноценный мессенджер — рано или поздно дешевле будет от такого подхода отказаться.
На самом деле эхо может быть из-за многолучевого распространения от одного источника. На средних волнах это бывает нечасто, но на коротких можно наткнуться и сейчас. Вообще вынужден признать, получилось правдоподобно. Кстати, АРУ немного не так работает, у него есть еще постоянная по времени, но так даже лучше для целей данного проекта — ибо появляются еще и нелинейные искажения.
Практика обычно показывает, что любой протокол нужно уметь готовить. REST без дополнительных ухищрений прверх TLS всегда будет плохо работать в нестабильной среде, но это не значит, что TCP плох. Готов поспорить, что разумное применение TCP будет в общем случае работать лучше, чем поделка на коленках на основе UDP. Есть хорошая книжка на эту тему — «Эффективное программирование TCP/IP» (Йон Снейдер). Она достаточно старая, но подробно рассматривает озвученную в статье проблему.
Блин, спасибо конечно за статью, но это хоть и сильно расширенное и дополненное, но всё-таки содержание школьного учебника физики, имеющее к небоскрёбу весьма отдалённое отношение. А мы тут на хабре, думаю, половина аудитории сайта и так в курсе, как работает громоотвод. Лучше расскажите, есть ли действительно необычные решения, связанные с особенностью конструкции? Есть ли проблемы с наведёнными токами в слаботочных сетях, например?
Расскажите, как оплачиваете? У меня со счёта в пейпал получается только за некоторые недешевые страны платить, в остальных случаях, требует привязанную карту той страны, за которую пытаюсь платить.
Про чатик — боюсь это так не работает.
Что же касается «а вдруг меня за это арестуют и будут судить, а там суд мне может нарисовать что-нибудь страшное» — так мне могут наркотики еще например подкинуть или кирпич на голову упасть — что теперь, на улицу не ходить?
Извиняюсь, проглядел
Ну, мне запомнились потери пакетов в диапазоне 30-50% на 64-байтных пингах. Сейчас, думаю, там так же или чуть хуже
Если у вас заранее известны особенности канала — понятное дело, заточенное под него решение будет работать лучше. То, о чем я пишу, я имею в виду в контексте глобальных сетей (плюс, желательно предусмотреть, чтобы толпа таких клиентов в одной локации не положила сеть лавиной ретрансмитов если вдруг аплинк на минуту пропадет)
Касательно очередности — да, согласен. Но тут имхо зависит от решаемой задачи. Лично я в контексте мессенжера предпочитаю подождать, пока соединение переподнимется и мне дойдут все сообщения, чем гадать, не потерялась ли часть смысла по пути. Если от этого отказаться — очевидно, UDP начинает подходить больше. И да, это именно то, что я имею в виду, когда говорю про аккуратное управление сессиями — то есть выставление таймаутов и переинициализация соединения, если оно залипло, если позволяет платформа — корректная установка опций сокета.
Разумеется, всё это я говорю в контексте коротких текстовых сообщений, если в ту же сессию полетят котики — разговор будет другой
Вы сравниваете теоретический мессенджер на базе UDP с современными реальными на базе TCP и делаете достаточно жирное допущение о том, что проблемы современных мессенджеров связаны с TCP. Я говорю о том, что при разработке реального мессенджера с конкретным набором требований (шифрование, аутентификация, медиаконтент, подтверждения) — может оказаться, что не такой уж большой выигрыш дает UDP. Да, концепт без шифрования и прочих рюшек на UDP скорее всего выиграет, но не будет жизнеспособен в реальных условиях.
Я считаю, что проблемы современных мессенджеров не в том, что они используют TCP, а в том, сколько ещё уровней (часто избыточных) они используют поверх него.
Косвенно, это подтверждает мой опыт использования IRC, ICQ и Jabber через ранний GPRS — проблемнее всего тогда у меня был Jabber, и если взглянуть на его протокол — он самый избыточный. Позднее, когда компрессия стала распространенным явлением, вся тройка более-менее сравнялась и далее их юзабилити ограничивалось только глюками и особенностями конкретного протокола.
Кроме того, в общем, уже существуют протоколы, которые по крайней мере в теории поддерживают все три транспорта и используют более подходящее управление сессиями (MTProto). И да, оно лучше, но я бы не сказал, что на столько же лучше на сколько сложнее такая полная реализация.
Ну право же, SYN-ACKSYN-ACK это три очень маленьких пакета. Да, это занимает время, но это не так страшно, как установка TLS сессии и аутентификация поверх — вот с этим действительно надо бороться, а тут что по UDP что по TCP overhead будет примерно одинаковым
В противовес этому, в варианте с TCP нужно просто написать нормальный менеджмент сессий. Но его для UDP какой-то тоже придется делать, хоть и попроще.
Справедливости ради, у TCP есть другая неявная проблема — особенности реализации под каждую ОС, например, разные таймауты по-умолчанию — но это можно и нужно решать менеджментом сессий.
В общем, если задачу ограничить как «доставить короткое сообщение немедленно и без шифрования» — UDP подойдёт. Если вы всё-таки хотите полноценный мессенджер — рано или поздно дешевле будет от такого подхода отказаться.
Показатели как у железофосфата примерно.
Вот ещё сравнение, тут точных цифр нет, но титанат отнесли по безопасности аналогичным железофосфату: batteryuniversity.com/learn/article/types_of_lithium_ion
При этом по удельной емкости они чуть хуже получаются.