«Reserved for future use»-синдром

Многие такие поля были использованы давно и сейчас просто оставлены для совместимости. Таким страдают старые протоколы.

И это тоже.

Почитайте про программирование ти-си-пи сокетов в юникс, я уже себе мозг сломал. И вроде не совсем неофит.

Многие такие поля были использованы давно и сейчас просто оставлены для совместимости. Таким страдают старые протоколы.

В этом-то и вопрос. Зачем делать такое, неужели так болезненно в будущем просто объявить новую версию протокола/апи (возможно, поломав совместимость), чем при создании пытаться телепатически узнать, что же в будущем может понадобиться.

В некоторых библиотеках сохраняют бинарную совместимость, а из хедеров выкидывают.

неужели так болезненно в будущем просто объявить новую версию протокола

ipv6_popularity.jpg

Cколько лет TCP/IP? И как долго вы наблюдаете подобный синдром? Уверен, лет этак 5-10 назад таких полей было поболе чем сейчас.

неужели так болезненно в будущем просто объявить новую версию протокола/апи

Да почти безболезненно.

NFS Version 4 (RFC 3010, December 2000;

2000, OK. Идём в 2011:

01-04-2011 I get an error

«Mount.nfs: access denied by server while Mounting 192.168.0.60: / opt/sybhttpd/localhost.drives/SATA_DISK_A1»

try specifying vers=3 as a mount option
It is necessary to specify nfs version because the nfs client will default on v4 on most Linux version and the PCH use version 3 of the NFS server

чем при создании пытаться телепатически узнать, что же в будущем может понадобиться.

Никто не пытается угадать, они уже использовались, но сейчас необходимость в них отпала. Делать новую версию протокола для такого - это слишком много усилии. Скорее всего никто эти поля больше использовать не будет. Хотя бы потому, что может быть ПО, которое еще помнит, что когда-то эти поля были не зарезервированы.

Как раз таки нет. Такие поля оставляют для возможности безболезненной функциональной масштабируемости в особенности для протоколов низкого уровня. Как они могли бы использоваться каким либо ПО если бы не были в спеке?

Они были в прошлой версии спецификации, и потом их убрали. При этом часто зарезервированное поле должно иметь специфическое значение чтобы оставаться совместимым со старыми устройствами.

Естественно не все поля такие, и каждое нужно обсуждать отдельно.

Я могу точно утверждать только про протокол ZigBee, где точно есть такие поля. Так же там есть поля, которые оставлены зарезервированными и обычно для этого есть обоснование, но оно обычно не доступно в публичных документах.

Зато штабильно.

ZigBee насколько помню прикладного уровня - это гораздо более безболезненно :) Не думаю, что это подойдет для tcp/ip. У нас только два варианта - ipv4 и ipv6.

ZigBee такой же транспортный протокол, которому нужно поддерживать совместимость со всеми прошлыми версиями. По числу костылей он близок к TCP/IP как никто другой.

IPv4 тоже не постоянен, значение полей изменялись на протяжении времени.

В железе такое любят, там reserved полей гораздо больше чем в tcp/ip. Всё потому что в похожих но разных железках какие-то части ведут себя по разному, тогда в даташитах те части которые не используются помечают как reserved.

Насколько я понял ТС, речь идет об сетевом уровне, raw data, это 3 (или 4 если ТС имеет ввиду именно TCP) уровень сетевой модели. Вы говорите о 7ом, для работы с которым нужно просто изменить поддержку протокола приложением(ми), его использующими. При изменении функционала каких то полей, битов, флагов, на данном (7ом) уровне, это пройдет гораздо более безболезненно, ну а ниже, tcp или ip - это менять весь интернет? :) Поэтому оставляют reserved поля и при добавлении каких либо значений это пройдет безболезненно, а при удалении или выставить им reserved - абзац неизвестно чему?

а при удалении или выставить им reserved - абзац неизвестно чему?

Гипотетический пример - поле «число переповторений в случае неудачной отправки», сначала ввели, а потом решили, что нафиг не нужно и навсегда сделали 0. Совсем убрать нельзя, вот и появилось Reserved поле.

Нужно в каждом конкретном случае смотреть и думать. Так что вопрос к ТС - какие именно поля смущают?

Нужно в каждом конкретном случае смотреть и думать. Так что вопрос к ТС - какие именно поля смущают?

Речь шла не только о полях tcp/ip. Но если нужны конкретные примеры, то их есть у меня.

http://tools.ietf.org/html/rfc2474#section-3
http://tools.ietf.org/html/rfc791#page-13 (Flags)
http://tools.ietf.org/html/rfc791#page-15 (Option classes)
http://tools.ietf.org/html/rfc5735#section-4 (240.0.0.0/4)
http://tools.ietf.org/html/rfc790

Предлагаю тебе отказаться от использования протоколов TCP/IP.

В случае c битовыми полями RFFU - это просто способ обозначить неиспользуемые биты. В случае перечислимых значений (rfc791) - это просто способ «добить» неиспользуемые значения. С точки зрения структуры документа лучше один раз написать, что все что RFFU нужно устанавливать в 0 при передаче и игнорировать при приеме, чем каждый раз объяснять что делать с неиспользуемыми значениями и битами.

В случае rfc791 вполне возможно, что в одной и ранних реализаций этот бит использовался для чего-то, а потом его в процессе выкинули. RFC пишут не в вакууме, сначала делают и отлаживают реализацию, а на ее основе уже и доку делают (часто в параллель, конечно).

Я в этом процессе принимал участие в живую на примере 6LoWPAN (rfc4944 и связанные), как писали изначальные стандарты не знаю, но думаю так же.

В случае c битовыми полями RFFU - это просто способ обозначить неиспользуемые биты.

С этим соглашусь. Но не целые октеты же, и даже более. Вот мне нравится то, как подошли к вопросу DHCP поверх BOOTP. Просто добавили новые Options, которые добавили семантику старому формату.

Аналогичная история (обилие reserved/obsolete полей) в протоколе ATA. Типично и оправданно для низкоуровневых протоколов, с которыми работают простые железки, которые однажды разработаны и должны эксплуатироваться годами и десятилетиями, без поддержки со стороны производителя.

Никому не нужно, чтобы в результате «гибкости» протокола у кого-то вдруг отказывали сетевые коммутаторы или накопители данных при работе с более современными сетевыми агентами или хост-контроллерами соответственно. Аппаратная инфраструктура - не программа, бесплатно не заапдейтишь.