на самом деле, мне не так важна дата выхода ядра: для меня в статье стали новостью такие слова как «open vSwitch», «Binder» и многие другие. Собственно за ради рассказать о них я и переводил текст ;)
Тема — разное:
Какова ситуация в регионах с услугами связи? (Почта, телефон, телеграф, сотовая связь, интернет. Последнее — по различным технологиям доступа: «мобильный» интернет, dsl, выделенные линии, оптоволоконные линии связи)
Существуют ли планы развития гражданских систем связи?
Существуют ли планы организации программ поддержки местных операторов связи?
Ведётся ли министерством работа по сбору статистики о проникновении различных услуг среди населения? Доступна ли эта статистика публично?
Существуют ли планы о переходе на полностью цифровые линии связи в федеральном и местном масштабах? Если существуют, на каком этапе выполнения эти планы?
Как министерство формирует требования к реализуемым программам? (В плане используемых технологий. Как пример — выбор программной платформы для определённой системы). Существует ли механизм «обратной связи» с министерством, для оптимизации подобных требований?
К атриксам всегда шёл очень интересный софт. В основном, это webtop, который может превратить телефон в почти полноценный десктоп. (и другие приложения, которые позиционируются моторолой как основные отличия от конкурентов).
Кроме того, для атриксов и дройдов есть замечательные док станции. Это, в первую очередь, lapdock. Не совсем понятно, что заставит человека отказаться от двух полноценных устройств и купить терминал к телефону, но сама идея — интереснейшая. Кстати, было бы интересно почитать про практику использования подобных док станций.
сравните это с постами на 400 и 500 комментариев и вы поймёте разницу. всё что меньше 50 комментариев, можно считать и не комментировали.
Кроме того, обратите внимание: у комментирующих почти всегда и без того много комментариев. Так что в основном статья верна. Ну и разве что из-за эффекта белой обезьяны тут появятся чьи-то ещё слова %)
ps. первый комментарий надо было писать как «да, ты прав, ублюдок». Было бы уместнее, я думаю.
Он действительно не устанавливал соединение ни с кем, так что примет не то что ответ, просто пакет откуда угодно.
Но особых плюсов это не даёт, имхо. Способов избежать «Received a packet from an unexpected server» я не вижу.
Вообще, почему я стал писать этот перевод: есть софт типа openvpn или asterisk, который использует udp, но всё же коннектится к удалённому хосту. И при использовании алиасов на интерфейсах, возникают различные фокусы, как в описанном выше варианте. Переписывать этот софт не получится, однако проблемы можно избежать сконфигурив сервис по другому. Перевод в основном для этого сделан ;)
Про отправку пакетов без connect'а — любопытно. Как-то я в таком виде клиентов не реализовывал…
по поводу nc я понял. nc не используется как сервер. Только как клиент. Кроме того, в некоторых версиях nc это поведение можно обойти. Клюс -k заставляет nc слушать последующие соединения после завершения текущего. Как этот ключ сочетаетс с udp я не очень представляю.
Поймите меня правильно: я примерно представляю себе как устроен echo сервер. Проблем с реализацией у меня не возникало ни разу. Вы же предлагаете изменение, суть которого я не очень понимаю. Потому я прошу вас привести конкретную реализацию: я соберу именно тот исходник, который вы предложите, и попытаюсь на нём показать в чём проблема.
Насколько я вас понимаю, хорошо бы ещё отказаться и от nc как клиента. Так что я готов принять от вас ссылку на реализацию клиента до кучи. (Хотя лучше просто в комментарий выложить исходник).
вы не могли бы привести полный исходник. Я пока не очень понимаю вашу мысль. То есть всё что вы говорите — верно, но какое имеет отношение к описанному выше я пока не пойму.
вы пропустили два «struct» в своём исходнике (у меня не компилилось, по крайней мере, пока не поправил).
Вы не могли бы привести пример исходника, который при этом шлёт ответ клиенту? Проблема не на приёме, проблема в доставке ответа клиенту.
Насколько я понимаю, сокеты делятся на принимающие данные с любого удалённого адреса и те, которые ждут пакеты с конкретного адреса. Для первых ещё не определена ответная сторона. Они слушающие. Вторые полностью заданы. Они используются для передачи данных конкретному адресату. При получении пакета из слушающего сокета создаётся сокет для передачи данных. Это позволяет обслуживать несколько клиентов одновременно (или псевдопараллельно). Где в ядро происходит это копирование, я сейчас не готов рассказать (я просто плохо понимаю, что там происходит при приёме пакета).
Со стороны отправителя сетевой стек ждёт ответа с того адреса, куда он отправил данные. Например:
oxpa@oxpa-desktop:~$ netstat -unp
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
udp 0 0 192.168.0.2:38940 8.8.8.8:53 ESTABLISHED 19597/operapluginwr
Видно, что задан как локальный адрес (192.168...), так и удалённый (8.8.8.8). Только эти два хоста могут обмениваться данными. Данные от третьей машины будут отброшены 192.168.0.2 как «шум».
А с другой стороны, вот ntp слушает сеть:
udp 0 0 127.0.0.1:123 0.0.0.0:*
—
Ответная сторона не определена.
В этом случае, я получу данные от любой машины. Данные мне пожет послать кто угодно.
Обычно, клиентские приложения рассчитаны на ответ с того адерса, куда послан запрос. Такое что слушаем на одном порту, а отвечаем на другом — редкость. Примером может служить DHCP, где и получатель и отправитель на первых этапах обмена данными неизвестны.
Если получилось путано — переспросите, я поясню иначе. На другом примере ;)
я на подобные железки ставил freebsd. Как-то линуксом ещё не увлекался. Удобны они тем, что могут работать очень тихо и выполнять роль полноценного домашнего роутера, почтового сервера и ещё чем-нибудь управлять. Строить вокруг такой железки «умный дом» разве что лениво.
А ещё были двухпроцессорные матери для P1-133. Вот на них уже можно уйму забавного сделать.
Странно, что вы не учите японский, суахили и нигерийский одновременно, при этом… Столько же всего теряете! Или всё же пренебрежимо мало, чтобы не морочится?
Какова ситуация в регионах с услугами связи? (Почта, телефон, телеграф, сотовая связь, интернет. Последнее — по различным технологиям доступа: «мобильный» интернет, dsl, выделенные линии, оптоволоконные линии связи)
Существуют ли планы развития гражданских систем связи?
Существуют ли планы организации программ поддержки местных операторов связи?
Ведётся ли министерством работа по сбору статистики о проникновении различных услуг среди населения? Доступна ли эта статистика публично?
Существуют ли планы о переходе на полностью цифровые линии связи в федеральном и местном масштабах? Если существуют, на каком этапе выполнения эти планы?
Как министерство формирует требования к реализуемым программам? (В плане используемых технологий. Как пример — выбор программной платформы для определённой системы). Существует ли механизм «обратной связи» с министерством, для оптимизации подобных требований?
Кроме того, для атриксов и дройдов есть замечательные док станции. Это, в первую очередь, lapdock. Не совсем понятно, что заставит человека отказаться от двух полноценных устройств и купить терминал к телефону, но сама идея — интереснейшая. Кстати, было бы интересно почитать про практику использования подобных док станций.
Кроме того, обратите внимание: у комментирующих почти всегда и без того много комментариев. Так что в основном статья верна. Ну и разве что из-за эффекта белой обезьяны тут появятся чьи-то ещё слова %)
ps. первый комментарий надо было писать как «да, ты прав, ублюдок». Было бы уместнее, я думаю.
Он действительно не устанавливал соединение ни с кем, так что примет не то что ответ, просто пакет откуда угодно.
Но особых плюсов это не даёт, имхо. Способов избежать «Received a packet from an unexpected server» я не вижу.
Вообще, почему я стал писать этот перевод: есть софт типа openvpn или asterisk, который использует udp, но всё же коннектится к удалённому хосту. И при использовании алиасов на интерфейсах, возникают различные фокусы, как в описанном выше варианте. Переписывать этот софт не получится, однако проблемы можно избежать сконфигурив сервис по другому. Перевод в основном для этого сделан ;)
Про отправку пакетов без connect'а — любопытно. Как-то я в таком виде клиентов не реализовывал…
Насколько я вас понимаю, хорошо бы ещё отказаться и от nc как клиента. Так что я готов принять от вас ссылку на реализацию клиента до кучи. (Хотя лучше просто в комментарий выложить исходник).
Вы не могли бы привести пример исходника, который при этом шлёт ответ клиенту? Проблема не на приёме, проблема в доставке ответа клиенту.
Перевод мой. Отвечать могу я (и за перевод, и по содержанию).
Со стороны отправителя сетевой стек ждёт ответа с того адреса, куда он отправил данные. Например:
Видно, что задан как локальный адрес (192.168...), так и удалённый (8.8.8.8). Только эти два хоста могут обмениваться данными. Данные от третьей машины будут отброшены 192.168.0.2 как «шум».
А с другой стороны, вот ntp слушает сеть:
—
Ответная сторона не определена.
В этом случае, я получу данные от любой машины. Данные мне пожет послать кто угодно.
Обычно, клиентские приложения рассчитаны на ответ с того адерса, куда послан запрос. Такое что слушаем на одном порту, а отвечаем на другом — редкость. Примером может служить DHCP, где и получатель и отправитель на первых этапах обмена данными неизвестны.
Если получилось путано — переспросите, я поясню иначе. На другом примере ;)
Шлюз, естественно, есть между этими сетями.
А ещё были двухпроцессорные матери для P1-133. Вот на них уже можно уйму забавного сделать.