«Слот на всякий случай» и три планки — не вариант, у вас двухканальная память, в двухканальном режиме она работает только тогда, когда в связанных слотах стоит память с одинаковыми характеристиками.
Но вообще-то не так это дорого. Если вы в хороших отношениях с провайдером, имеющим собственный LIR — то может быть и вообще бесплатно. Если через посредников, на этом специализирующихся — порядка $200/год за блок адресов.
А тогда не парьтесь и делайте проще — берите любую приватную сетку, например 10ю, назначайте оттуда диапазон, документируйте и давайте возможность поменять — так поступают даже достаточно крупные производители, тот же Microsoft для настроек удаленного доступа в отсутствии DHCP. А вот 169.254 для таких целей не годится, не должно быть двух сегментов где используются эти адреса.
Судя по описанному, это скорее готовая писишная платформа, у которой мак-адрес физического интерфейса будет или от производителя материнки или от broadcom/marvel. Решение без регистрации OUI есть — купить две сетевых карты, взять их MACи после чего торжественно запереть в сейф. Но как-то это не по-промышленному, использовать чужой OUI.
169.254 можно использовать только при выполнении всех условий:
1. «внешний» интерфейс всегда подключен или при его переподключении сбрасывается внутренний интерфейс
2. на внешнем интерфейсе имеется возможность поднять ARP-прокси, которая будет отвечать адресом внутреннего интерфейса, чтобы ни одно другое устройство не село на тот же адрес.
3. для адреса назначаемому внутреннему интерфейсу будут производиться проверки предусмотренные RFC 3927, чтобы убедиться, что он не занят.
И все равно это не гарантирует ничего, т.к. amazon используется эту сеть для своих серверов, например.
Знаю несколько крупных интернет-провайдеров, использующих 10.0.0.0/8 для клиентов, 192.168.0.0/16 для оборудования и 172.22.16.0/20 для собственной внутренней сети.
LGPL позволяет создать коммерческий проект с закрытым кодом, если весь лицензированный код вынести в отдельные библиотеки. Скорее, подходит просто GPL.
Так а причем тут блокирование ACK или RST? Нет там никакого блокирования, просто никто их не отправляет. ACK со стороны сервера не отправляется, т.к. данные из буффера не считываются, принимающая сторона не хочет получать новых данных. RST тоже никто не отправляет, для этого нет никаких причин — все идет строго по протоколу, ретрансмиты полученных ранее пакетов молча отбрасывается.
If the peer calls close() or exits, without having messed with
SO_LINGER, then our calls to read() should return 0. It is less clear
what happens to write() calls in this case; I would expect EPIPE, not
on the next call, but the one after.
If the peer reboots, or sets l_onoff = 1, l_linger = 0 and then
closes, then we should get ECONNRESET (eventually) from read(), or
EPIPE from write().
Линк был в самом первом посте. RFC тут никаким боком, это системный API. К сожалению, какой-либо более «официальной» документации по Linux для случая l_linger=0 я не знаю, но в микрософтовской документации четко сказано, что удаленный конец при таком закрытии (abortive close) получает именно reset.
При нулевом лингере удаленному концу принудительно шлется RST и соединение закрывается, на все последующие пакеты приходят RST. При ненулевом лингере на пакеты, которые пришли в рамках соединения, даже если это ретрансмиты после FIN, RST не шлется.
по strace'у что-то немного странное. Обычно в nfds пишется sock+1, если sock — максимальный сокет в FD_SET, почему там 16, если 15й сокет не в списке — какой-то подвох. Если б меня сильно интересовал вопрос — таки я бы заглянул в сорсы и посмотрел что там за select и что происходит по Ctrl+C.
Еще можно проверить nmap'ом — если на попытку ACK-скана на недавно закрытый порт RST возвращается, значит причину точно следует искать в лингерах.
When enabled, a close(2) or shutdown(2) will not return until all queued messages for the socket have been successfully sent or the linger timeout has been reached. Otherwise, the call returns immediately and the closing is done in the background. When the socket is closed as part of exit(2), it always lingers in the background.
