Основные установки обслуживания файловых запросов.
Рассмотрим основную сетку ввода строк из диалогового окна конфигурации файловых запросов. В ней перечисляются каталоги, в которых содержатся файлы, предназначенные для пересылки по запросам, пришедшим во время сеанса связи. Для каждого каталога может быть задан пароль. Количество определяемых каталогов не ограничено. Перечисленные в pathnames каталоги, вмесите с подкаталогами и файлами, называются "файловой базой".
При отключенной опции почтовая система индексирует базу, и на поиск уходит уже меньше секунды, однако после каждого обновления файлов индексы также подлежат обновлению.
Часто встречается случай, когда запрос осуществляется не по имени файла, а по псевдониму. Например, общеупотребителен псевдоним FILES. При запросе этого "файла" передается файл, содержащий полный список всех файлов системы. У каждой системы этот файл имеет собственное уникальное имя, но почти везде можно запросить FILES и получить что-нибудь вроде rz-all.zip в ответ.
В поле Alias сетки ввода строк Alias прописывается псевдоним файла, в поле Path - путь к файлу, который будет отдаваться по этому псевдониму, а в поле Password - необязательный пароль.
В псевдонимах файловых запросов можно использовать маски (как в поле Alias, так и в поле Path). Предшествующий символ '>
' означает самый свежий файл, попадающий под эту маску. На один псевдоним можно назначить несколько файлов, перечислив их через пробел.
Аргус имеет возможность вызывать внешний обработчик файловых запросов посредством стандарта SRIF (Standard Request Information File), который разработали Gordian Schuermann & Mirko Mucko.
Использование внешнего обработчика разрешается опцией Use SRIF. При этом остальные вышеописанные настройки файловых запросов игнорируются, и вся забота перекладывается на плечи внешнего обработчика. Суть метода SRIF заключается в передаче данных внешнему обработчику через временный файл, который создается почтовой системой при файловом запросе.
Имя исполнимого файла внешнего обработчика задается в поле Standard Request Information File - External Processor. Ключевое слово %SRIF%
в этом поле заменяется на имя временного файла.
Пример поля при использовании AllFix © Harms Software Eng.:
c:\fido\allfix\allfix Rp -SRIF %SRIF%
The Service Request concept is is very similar to the SRIF ERP (described above). In both cases, an external application is used to serve file requests. Unlike SRIF, when one application is launched to serve a whole batch of requested file, Service Requests allow to run a particular application for each requested item. Service Requests cannot coexist with SRIF. To user Service Requests turn "Use SRIF" checkbox off. Service Requests are typically used to invoke programs that update databases, or sends specific files only after checking a database for specific information (product updates for example).
Service Requests are defined in the file request alias list (Aliases string grid) by placing an equal sign ('=
') as a first character in "Path" column . E.g.
Alias | Path | |
PRODUCTUPDATE | =C:\SR\PRODUPD.EXE ^<symbol><filemask> |
where C:\SR\PRODUPD.EXE
is the program to execute, ^<symbol>
defines what Argus should do with the files matching <filemask>
after the session has been completed. Wildcards and Regular Expressions in <filemask>
are only allowed in name section, not in path section. E.g. c:\games\*.*
is valid in but c:\games\*\readme.txt
is invalid.
^
character and <filemask>
are mandatory, <symbol>
is optional. If no <symbol>
is specified, the Mailer assumes that all files matching <filemask>
should be removed after the session has been completed regardless of the transmission status of each file.
Priority modifiers for Low, High and Real-Time classes can be specified same way as for SRIF.
Executable path/file name and parameters may contain special handshake switches (also called macros, same as Handshake Switches for Doors and External Polls) that are translated into appropriate string values before the application is started. Each command switch starts with the percent symbol followed by a command character. All handshake command line switches are case sensitive, for example %c
may not be used instead of %C
.
For each possible handshake switch an Environment variable is also created, which could be used by launched application. Even if no hadshake switches are specified in executable path/file name and parameters, all Environment variables are created.
The following switches return caller's primary address and nodelist information (if any).
Environment | Description | |
|
|
Remote primary node address string, eg "2:469/38" |
|
|
Station name from nodelist for remote primary address, if listed |
|
|
Site location from nodelist for remote primary address, if listed |
|
|
Sysop's name from nodelist of remote primary address, if listed |
|
|
Phone number or IP address from nodelist of remote primary address, if listed |
|
|
Node flags from nodelist of remote primary address, if listed |
|
|
Node speed from nodelist of remote primary address, if listed |
The following switches return line and connection information and vary for dial-up and TCP/IP connection.
Environment | Description | Dial-up value | TCP/IP value | |
|
|
Connect speed | DCE (modem to modem) | as assumed in TCP/IP Daemon configuration dialogue box |
|
|
Port speed | DTE (computer to modem) | same as %B |
|
|
Connect string (spaces replaced to underlines) | as returned after modem CONNECT word, e.g.:
" |
as returned after Argus TCP/IP CONNECT word, e.g.:
" |
|
|
Translated error control code | "MNP " if any of MNP, ARQ or REL string is present in the connect string. Otherwise null. |
Always "TCP/IP " |
|
|
Mailer line name (spaces replaced to underlines) | as in dial-up/lines/line name | "TCP/IP" plus number of TCP/IP connections, e.g.: "TCP/IP 3 " |
|
|
Mailer line number | Number of entry in dial-up/lines list, e.g. "1 " for the first line listed. |
Number of active TCP/IP connection, e.g. "2 " for "TCP/IP 2" line |
|
|
Communication resource handle | COM port Win32 handle | WinSock2 overlapped socket handle |
|
|
Port number | COM port number, e.g.: "1 " for COM1 or "4 " for COM4 |
TCP/IP port number, e.g.: 24554 for BinkD |
|
|
Port index | zero-based COM port number, e.g.: "0 " for COM1 or "3 " for COM4 |
same as %C |
Special %Z
switch is also allowed here and works same way as in Doors.