Nick Filimonov - 64 килобайта о Фидо

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

Под сессией дальше будем понимать процесс установления связи между двумя мейлерами после физического соединения двух модемов. Для обнаружения присутствия мейлера на другом конце провода или определения звонка терминалом пользователя ББС используются различные протоколы сессий.

Hаиболее популярными в настоящее время являются протоколы EMSI (емзи, емси, сокр. от Electronic Mail System Interface). Различают оригинальный протокол EMSI, применяемый при связи двух роботов-мейлеров, и интерактивный протокол EMSI (IEMSI — Interactive EMSI), используемый для более удобной связи с ББС с помощью терминала. Мы будем рассматривать лишь первый из них.

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

После установления физического соединения станция, ответившая на звонок, обычно посылает в линию строку идентификации мейлера (introduction), которая может содержать информацию о сетевом адресе и предложение для пользователей ББС нажать ESC-ESC. За этим обычно следует передача специальной последовательности символов, называемой EMSI-запросом (EMSI_REQ). Станция послыает эти запросы в течение определенного времени, и, не получив ответа, или получив ESC-ESC переходит в режим вызова ББС или вешает трубку, если ББС недоступна.

Звонящий узел аналогичным образом передает приглашение на EMSI-сессию (EMSI_INQ). После выяснения обоюдной поддержки EMSI станции обмениваются EMSI_DAT пакетами и приступают к передаче файлов. Детали реализации протоколов EMSI и IEMSI описаны в стандартах сети FIDONet (FSC-0056).

Установление связи между двумя узлами вышеописанным образом называется EMSI-handshake (емси-хэндшейк)

Этот вопрос включен в рассмотрение ввиду распространенности проблем с соединением при ошибках в задании паролей.

Прежде всего, имеет место следующая таблица :

Звонящий узел | Отвечающий Узел | Сессия

пароль | вид сессии пароль | вид сессии

нет непарольная нет непарольная +

есть парольная нет непарольная ? *)

нет — есть — —

есть парольная есть парольная + (пароль совпал)

есть — есть — — (несовпал)

* — зависит от мейлера и его настроек.

Пароль проверяется на этапе EMSI-handshake. Запомните, что несмотря на то, что многие мейлеры позволяют использовать пароли произвольной длины (например, T-MAIL), большинство все же придерживаются ограничения в 8 символов. Если предъявленный пароль окажется длиннее имеющегося сессия не будет установлена.

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

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

Как правило, эхопроцессоры подразделяются по форматам баз писем, с которыми они способны работать. Существуют следующие форматы баз :

— *.MSG. В этом формате каждое письмо находится в отдельном файле, имеющем числовое десятичное имя и расширение MSG. Каждая конференция в таком формате попадает в отдельный каталог. Это одна из самых медленных и неэффективных баз — под каждый файл вне зависимости от его размера расходуется как минимум 4 Kb пространства жесткого диска, а ограничения DOS позволяют эффективно работать не более чем со 100 файлами в каталоге. Hекоторое убыстрение возможно посредством установки программы FASTOPEN или дискового кэша.

— Hudson. В этом формате все конференции размещаются в одном файле. Это наиболее быстрый из всех известных форматов, однако структура файла Hudson-базы легко может быть нарушена посредством внезапного отказа аппаратуры или появления сбойного сектора. В таком случае Вы рискуете потерять все письма во всех областях.

— JAM. (Первые буквы имен авторов : Joaquim-Andrew-Matthew) Hекоторый компромисс между скоростью Hudson и надежностью MSG. В этом формате конференции хранятся в разных файлах, по четыре файла на область. Возможно разнесение разных конференций в разные директории и т.д.

— Squish. Этот формат аналогичен JAM, с той разницей, что в JAM-базе новые письма всегда добавляются в конец базы, которая может довольно долго раздуваться в размерах, а в Squish-базе имеется возможность ограничить число писем и поддерживать его автоматически.

— другие форматы.

Для успешной обработки писем эхопроцессоры и редакторы используют механизм указателей на последнее прочтенное письмо (Lastread Pointers). Для каждого пользователя станции хранится номер последнего прочтенного им письма в каждой области. Таким образом вместо полного просмотра всей базы тоссеру или редактору достаточно исследовать еще непрочтенные письма. Это позволяет в частности организовать быстрый поиск личной почты при входе пользователя на BBS.

Как правило в эхопочте ведутся дискуссии (за исключением конференций, где дискуссии запрещены). Для того, чтобы иметь возможность просмотреть ответы других участников конференции на заинтересовавшее Вас письмо, существует другая функция эхопроцессора — построение (или связывание) цепочек вопрос-ответ (Reply Chains Linking). Hекоторые эхопроцессоры осуществляют такое связывание автоматически, некоторым для этого требуется указание специального ключа командной строки (Обычно это ключ Link).

Эхопроцессор, помимо указанных ранее функций, должен обеспечивать обслуживание базы (т.н. удаление писем (purge) и упаковку базы (pack)). Раз в неделю (или другой промежуток времени, определенный оператором станции) по специальной команде (purge) эхопроцессор должен осуществить поиск писем, устаревших по дате написания или по числу писем в базе и пометить их, как удаленные. Затем (по команде pack) удаленные письма физически удаляются из базы.

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

Более подробные сведения о Вашем эхопроцессоре Вы можете узнать из его документации.

Большую часть времени станция обычно находится в состоянии ожидания звонка или события. События определяются конфигурацией событий мейлера. Если пришло время очередного события, мейлер запускает определенные оператором процессы (например, тоссер).