TDM маппер: "чистить хвосты"

[san]

Не первый раз слышу от пользователей предложение добавить опцию: "Чистить хвосты старых коммутаций".
Вот что должно происходить после включения опции: "Если два канала A и B скоммутированы друг в друга, а пользователь производит новую коммутацию в ячейку A, то в ячейку B автоматически записывается значение Очистить.
На примере:

• Было:

1:5 -> 2:7
2:7 -> 1:5

• Пользователь коммутирует 3:4 -> 1:5 (нарушая прежнюю коммутацию 2:7 -> 1:5)

• В ячейку 2:7 автоматически записывается значение "Очистить" ("удаляется хвост" 1:5->2:7 )

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

p.s. Я, честно говоря, не вижу необходимости в данном улучшении, но для объективности добавил.

[alx]

Replying to san:

это должно упростить процесс изменения коммутаций, сделать его более наглядным.

Мое мнение я пока не понял ни каким образом эта функция может упростить процесс, ни каким образом она может сделать его более наглядным. Обещаю подумать об этом еще некоторое время...

[san]

Попробую чуть пояснить:
Пользователь разорвал соединение, "освободившаяся" ячейка автоматически очищается и взглянув в маппер стазу видно что она свободна (Например, освободилось место в полосе DSL и там можно передать ещё канал) А если автоматически она не очистится, то выглядит она так-же как и занятая нужной коммутацией и пользователь может, например, забыть что ячейка свободна.

[alx]

Как и обещал, я подумал. Нахожу предложенную функцию не только не полезной, но даже вредной. Попробую изложить аргументы.

В описанном сценарии тот факт, что в канал 1:5 скоммутировали канал 3:4, не означает, что канал 2:7 теперь стал "свободным", и соединение 1:5 -> 2:7 больше не нужно. На каком основании делается такой вывод? Нет логической связи между существованием соединения 3:4 -> 1:5 и свободностью канала 2:7. Чтобы сделать вывод о том, нужен канал 2:7 или нет, надо знать, куда он идет: допустим, в слоте 5 стоит плата FS-08 и, следовательно, канал 2:7 идет в ее порт 8, в который, согласно проекту (писанному или неписанному, а существующему в голове оператора) не предполагается ничего подключать. Об этом знает человек, выполняющий коммутацию, но у самого блока 3U недостаточно информации для того чтобы сделать вывод о свободности или занятости канала 2:7.

Далее, предположим, что такая функция реализована, и у нас есть все те же соединения 1:5 ->2:7 и 2:7 -> 1:5. Это рабочий двухсторонний канал, требуемый по проекту. Теперь для проведения некой проверки (например измерения затухания канала) оператор коммутирует в 1:5 канал 3:4 (предположим, туда подан измерительный сигнал с генератора). Выполнили измерение, убедились, что все хорошо, и опять подали в канал 1:5 канал 2:7, как и было раньше. И с чувством хорошо выполненной работы все пошли в отпуск. Вот только канал после этого не работает, так как в 2:7 теперь подается константа, так как он был автоматически очищен. Диверсия.

Считаю, что если оператор желает каким-то образом зафиксировать факт свободности или занятости канала, то ему придется делать это самому, своей собственной головой. Автоматика голову здесь не заменит. Можно каким-либо образом помочь оператору в этой задаче, например, показать каналы, в которые что-то скоммутировано, но которые, в свою очередь, не скоммутированы никуда, но полностью выполнить эту задачу за оператора невозможно...