Telnet по полудуплексному каналу связи — параметры согласования

Нашей встроенной системе нужен интерфейс Telnet (через последовательный порт), поскольку аппаратное обеспечение/устаревшая система работает по полудуплексному каналу (RS485). Да, я знаю — нет, мы не можем это изменить, индустрии так нравится.

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

Telnet поддерживает команду IAC->GA (Go Ahead), чтобы сообщить пользовательскому терминалу, что он может начать отправку данных, но ни в одном из RFC, которые я читал, нет информации о том, что сообщает пользователю терминал, чтобы остановить отправку данных, чтобы мы могли обновить экран.

К сожалению, все RFC после 1973 года предполагают, что будет использоваться режим SGA (Suppress Go Ahead). поэтому об этом очень мало упоминают. К сожалению, похоже, что не существует единого RFC или другого документа, который бы фактически охватывал весь протокол.

Есть ли у кого-нибудь информация/ссылки, которые более полно документируют протокол telnet (или просто поведение Go Ahead)? Я понимаю, что некоторые из них, вероятно, написаны на пергаменте с зелеными полосами ;)

RE-Edit: Почему этот вопрос о программировании закрыт "не по теме"? Telnet — это седьмой уровень модели OSI, знаете ли…


c embedded legacy telnet obsolete
person John U    schedule 11.10.2012    source источник
comment
Я тоже удивляюсь, почему это было закрыто. Тот факт, что telnet и RS485 не являются широко распространенными горячими темами, не означает, что вопрос недействителен или бесполезен.   -  person Michael Burr    schedule 16.10.2012
comment
Я подозреваю, что люди увидели RS485 и решили, что это аппаратное обеспечение или что-то в этом роде. Проклятые дети, убирайтесь с моей лужайки!   -  person John U    schedule 16.10.2012

Ответы (1)


arrow_upward
3
arrow_downward

Аааа... RS-485... Хорошо помню! :-)

Определение GA не работает (см. http://tools.ietf.org/html/rfc596) но должно быть хорошо для реализации последовательной линии, потому что пакеты не разбиваются.

То, что вы просите, это «обратный перерыв»:

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

По своей природе «разрыв» (обратный или иной) должен быть внеполосным в полудуплексном соединении, поскольку он должен иметь возможность быть отправленным в любое время.

EDIT: Новая информация в результате чата: Однако, если вы не ожидаете прерывания фактической передачи (и допустимы случайные искажения/обрывы передачи, и Программа telnet правильно реализует этот довольно необычный крайний случай, тогда отправка этого кода внутри диапазона может быть приемлемой.

Другой способ, который я могу придумать, чтобы справиться с этим, - это взломать программу Telnet на стороне клиента, чтобы периодически отправлять пакет «добро» на сервер, даже если ему больше нечего отправлять. Это позволит серверу выполнить обновление и в ответ дать добро; это что-то вроде «токен-ринга». Вам даже не пришлось бы откладывать - получив "добро", отправьте все ожидающие данные (может быть, ни одного), а затем верните "добро".

Возможное альтернативное решение:

Поскольку вы также контролируете устройство ser->ip, почему бы просто не использовать специальный протокол между сервером и устройством?

  • сервер отправляет STX data stream ETX

  • клиент отправляет STX data stream ETX

  • повторить без промедления

Если какая-либо из сторон не имеет данных в своем буфере данных, то это просто пара STX ETX, эффективно говорящая другой стороне «продолжать». Если в течение 250 мс с другой стороны ничего не приходит, повторно отправьте ETX

Вы даже можете расширить это, чтобы иметь обнаружение ошибок, перейдя STX data stream ETX CRC1 CRC2 с ответом NAK (вместо STX ...) в случае обнаруженной ошибки и вызвав повторную передачу всего последнего пакета.

person Brian White    schedule 11.10.2012
comment
Интересно - но у нас нет контроля над клиентом; мы являемся сервером, говорящим по 485-ссылке, которая проходит через IP-кодировщик, а затем к ней обращается пользователь, используя что-то вроде PuTTY. Звучит так, как будто это может сработать, так это то, что когда мы хотим начать говорить, мы отправляем обратный разрыв, за которым следует экран, полный данных, а затем Go Ahead — звучит ли это разумно? - person John U; 11.10.2012
comment
Это становится более сложным, поскольку вы ограничены тем, что может поддерживать терминал и конвертер. Какое устройство 485‹=›TCP вы используете? Какие варианты эха и режима линии вы обсуждаете? - person Brian White; 11.10.2012
comment
Мы используем доморощенную дань уважения remserial. Мы не дошли до согласования эхо/линейного режима. Еще одна проблема, о которой стоит упомянуть, заключается в том, что некоторые экраны отображают живые данные из нашей системы, поэтому в некоторых случаях экран обновляется с частотой ~ 1 Гц. Навигация осуществляется с помощью клавиш со стрелками, вход в систему и т. д. выполняется в обычном стиле командной строки. Устаревшие системы — это весело, а? :D - person John U; 11.10.2012
comment
Ну, это небольшая проблема. Я не могу поместить свою идею в комментарий, поэтому я отредактирую ответ. - person Brian White; 12.10.2012
comment
@JohnU, когда у вас что-то получится, я хотел бы услышать, какое решение вы выбрали. - person Brian White; 17.10.2012
comment
Пока все, что я выяснил, это то, что отправка перерыва, затем отправка данных, затем отправка доброго ответа, возможно, является ответом. Я немного ввел в заблуждение в приведенном выше комментарии - одно из наших приложений использует IP-конвертер, а другое - прямой RS485, и мы также хотели бы использовать терминальный интерфейс поверх него - так что проблема на самом деле просто HTF для полудуплекса Телнет правильно? Древние, казалось, справились с этим, но их убили из-за RFC400, и они больше никогда не упоминались. - person John U; 17.10.2012
comment
Не существует полнофункционального полудуплексного телнета, по которому любая сторона могла бы отправлять сообщения в любое время. Если вы можете включить прием и передачу 485 отдельно, вы можете реализовать разрыв строки, просто написав разрыв по входящим данным, и заставить другую сторону обнаружить его, читая при передаче и замечая, что есть повреждение на линии. Ethernet работает примерно так, поскольку изначально является полудуплексным. - person Brian White; 17.10.2012
comment
Правда, нет стандарта, по которому обе стороны могут отправлять в любое время, но, безусловно, заставляя использовать GO_AHEAD и BREAK (или что-то еще), чтобы сигнализировать другому концу, может / не может Tx, он должен работать только с иногда пропадает BREAK. В противном случае было бы приемлемо поведение в стиле циклического перебора/токен-ринга, когда каждая сторона по очереди. Протокол, по-видимому, поддерживает это, поскольку RFC596 является обсуждением нерекомендуемого такого поведения. - person John U; 17.10.2012
comment
Проблема в ПЕРЕРЫВЕ. Как вы это сообщаете? Если это символьный код и передается без внимания, он может столкнуться с передачей в другом направлении. И входящие данные и разрыв будут повреждены. Не говоря уже о том, что 485 обычно не слушает во время передачи (иначе он увидит свои собственные исходящие символы). - person Brian White; 17.10.2012
comment
Именно так, но я думаю, что мы можем допустить случайное столкновение символа BREAK. То, что я копаю, - это описание ожидаемого поведения - является ли BREAK правильной вещью для отправки, чтобы закрыть другой конец, или это одна из тех де-факто вещей, которые могут/вероятно работать и т. д. - person John U; 17.10.2012
comment
давайте продолжим это обсуждение в чате - person Brian White; 17.10.2012