Костыль, созданный с одной целью — вставить его, как палку, в колеса тому, кто будет расширять этот код.
Вернее, не так.
Это — костыль, который ясно вам скажет: не надо повторять мою реализацию, хочешь пакет больше — указатели, динамическая память и динамическое вычисление размера тебе в помощь!
Это — пример того, как делать не стоит. Никогда. Иначе случится насилие. Рано или поздно.
если мы захотим сделать реализацию, в которой размер пакета будет вычисляться динамически (из соображений этики и следования стандартам, только такая реализация и имеет право на жизнь)
Это бессмысленное усложнение, т.к. нужна структура/буфер под максимальный размер DHCP пакета. Динамика — оверкил в условиях, когда пакеты обрабатываются строго последовательно и максимальный размер пакета заранее известен.
Если DHCP клиент не обозначил серверу максимальный размер (57 опция), то сервер не имеет права по RFC отвечать пакетами бОльшего размера. Однако, это только в идеальном мире, поэтому есть опция UDHCP_SLACK_FOR_BUGGY_SERVERS, в которой задается размер дополнительного места в буфере с максимумом 924, что дает возможность принимать пакеты до 1500 байт.
См. https://git.busybox.net/busybox/commit/?id=72e76044cfda377486a5199a0d35d71edf669a42
Такой небольшой размер — прямое противоречие RFC с описанной в нем 57й опцией.
Никакого противоречия нет. Такой небольшой размер находится в полном соответствии с минимальным MTU, ниже которого быть не может. Соответственно, т.к DHCP протокол основан на UDP без подтверждения доставки, этот небольшой размер дает "гарантию", что DHCP пакеты не потеряются по пути из-за более меньшего MTU.
Чтобы информировать сервер о максимально поддерживаемом размере, добавляется 57 опция, с размером — IP_UDP_DHCP_SIZE == 576, вне зависимости от дополнительного буфера UDHCP_SLACK_FOR_BUGGY_SERVERS.
См. коммиты 2007 и 2010 года: https://git.busybox.net/busybox/commit/?id=35ff74676b54b1cae5a6324d2517568393fedbc8 https://git.busybox.net/busybox/commit/?id=b3af65b95de883e9be403e065f57b867d8ea8d43
Таким образом, чтобы "законно" получать пакеты больше стандартного размера, нужно
1) увеличить размер UDHCP_SLACK_FOR_BUGGY_SERVERS до максимально возможного
2) уведомлять сервер о реально поддерживаемом размере 57й опцией с учетом текущего MTU интерфейса.
И тут, всё давно придумано https://github.com/wl500g/wl500g/commit/57fd93bd29399d6b08643bb79a3e41f330b6cd9a
стоит добавить, что поддерживается до 50 зон, включая возможность прописать обратные.
апишка совместима dyndns клиентом, либо пользоваться простенькими скриптами.
либо — использовать мощный ddns прокси https://www.dnsomatic.com/, который умеет многое, в т.ч. dns.he.net
в плане синтаксиса, пример с передачей сигналов потомкам процесса, мне кажется, был бы нагляднее.
а на «зашифрованный» брейнфак вероятно придется получать нотацию фсб
спасибо за предложение, время бы еще найти.
а пока, последние оригинальные исходники (до x64 версии со сломанным уникодом и до всасывания в общий реп miranda-ng) — тут https://github.com/themiron/historypp/
используя свободное ПО, саботируют саму идеологию Open Source
автор которого, используя тот же Transmission и разместив GPL в корне исходного кода проекта, всеми правдами и неправдами препятствует его развитию, считая его своей собcтвенностью.
на здоровье, делалось для себя, заодно и delphi изучился :)
а насчет несложных штук,… анимация смайлов в richedit'е оказалась той еще болью, на момент реализации аналогов не было (либо я не нашел).
https://github.com/sigsergv/nginx/commit/50914051b751f5b7f0fa1a479fdea44a7f054c57#comments
мы точно об одном и том же proxy protocol?
я про https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt
в mtprotoproxy
поддержка PROXY protocol добавлена
да, с этими новыми возможностями win консоли получилось бы очень достойно.
Вы не поняли, и делаете неправильные выводы.
Это проверка, что компилятор корректно упаковал структуру с нужным размером.
См. https://git.busybox.net/busybox/commit/?id=6884f665bd7bc101f56ff9047afaffbc06dc99e2
Это бессмысленное усложнение, т.к. нужна структура/буфер под максимальный размер DHCP пакета. Динамика — оверкил в условиях, когда пакеты обрабатываются строго последовательно и максимальный размер пакета заранее известен.
Если DHCP клиент не обозначил серверу максимальный размер (57 опция), то сервер не имеет права по RFC отвечать пакетами бОльшего размера. Однако, это только в идеальном мире, поэтому есть опция UDHCP_SLACK_FOR_BUGGY_SERVERS, в которой задается размер дополнительного места в буфере с максимумом 924, что дает возможность принимать пакеты до 1500 байт.
См. https://git.busybox.net/busybox/commit/?id=72e76044cfda377486a5199a0d35d71edf669a42
Никакого противоречия нет. Такой небольшой размер находится в полном соответствии с минимальным MTU, ниже которого быть не может. Соответственно, т.к DHCP протокол основан на UDP без подтверждения доставки, этот небольшой размер дает "гарантию", что DHCP пакеты не потеряются по пути из-за более меньшего MTU.
Чтобы информировать сервер о максимально поддерживаемом размере, добавляется 57 опция, с размером — IP_UDP_DHCP_SIZE == 576, вне зависимости от дополнительного буфера UDHCP_SLACK_FOR_BUGGY_SERVERS.
См. коммиты 2007 и 2010 года:
https://git.busybox.net/busybox/commit/?id=35ff74676b54b1cae5a6324d2517568393fedbc8
https://git.busybox.net/busybox/commit/?id=b3af65b95de883e9be403e065f57b867d8ea8d43
Таким образом, чтобы "законно" получать пакеты больше стандартного размера, нужно
1) увеличить размер UDHCP_SLACK_FOR_BUGGY_SERVERS до максимально возможного
2) уведомлять сервер о реально поддерживаемом размере 57й опцией с учетом текущего MTU интерфейса.
И тут, всё давно придумано
https://github.com/wl500g/wl500g/commit/57fd93bd29399d6b08643bb79a3e41f330b6cd9a
стоит добавить, что поддерживается до 50 зон, включая возможность прописать обратные.
апишка совместима dyndns клиентом, либо пользоваться простенькими скриптами.
либо — использовать мощный ddns прокси https://www.dnsomatic.com/, который умеет многое, в т.ч. dns.he.net
тогда варианты могут быть — в оптимизациях gcc под эту архитектуру и/или в типе поддержке fpu в ядре
первое, что в голову приходит — собрано с CONFIG_NOMMU=y?
а на «зашифрованный» брейнфак вероятно придется получать нотацию фсб
а пока, последние оригинальные исходники (до x64 версии со сломанным уникодом и до всасывания в общий реп miranda-ng) — тут https://github.com/themiron/historypp/
можно поподробнее?
а насчет несложных штук,… анимация смайлов в richedit'е оказалась той еще болью, на момент реализации аналогов не было (либо я не нашел).
вот тут еще немного про используемое оборудование и причины его выбора, плюс видео бэкстейджа на 18 минут.
golbii.com/madmax
в смысле без расширений gcc и применения ассемблера?