Примеры сетевых топологий


Finger - часть 2


В случае выполнения запроса она должна это подтвердить:

Сообщая, что:

ЭВМ <H1> открывает соединение Finger <F1-2> с RUIP на ЭВМ <H2>.

<H1> выдает <H2> RUIP запрос <Q1-2> типа {Q2} (например, FOO@HOST1@HOST2).

При этом следует извлечь информацию о том, что:

ЭВМ <H2> является самой правой ЭВМ в запросе <Q1-2> (например, HOST2)

Запрос <Q2-3> является остатком запроса <Q1-2> после удаления правой части "@hostname" (например, FOO@HOST1)

Таким образом:

<H2> RUIP должна открыть соединение <F2-3> с <H3>, используя <Q2-3>.
<H2> RUIP должна прислать любую информацию, посланную от <F2-3> к <H1> через <F1-2> .
<H2> RUIP должна закрыть <F1-2> в нормальных обстоятельствах только когда <H3> RUIP закрывает <F2-3> .

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

Запрос {C} требует выдачи списка всех работающих пользователей. RUIP должна либо ответить, либо активно отказаться. Если она отвечает, тогда она должна выдать, по крайней мере, полные имена пользователей. Системный администратор может включить в выдачу и другую полезную информацию, такую как:

  • Положение терминала

  • Расположение офиса

  • Рабочий номер телефона

  • Должность

  • Время пребывания в пассивном состоянии (число минут с момента ввода последнего символа или со времени завершения последней сессии).

Запрос {U}{C} является требованием присылки информации о статусе определенного пользователя {U}. Если вы не хотите выдавать такую информацию, тогда следует заблокировать работу Finger.

Ответ должен включать в себя полное имя пользователя. Если пользователь активно работает в сети, то присылаемые данные должны включать, по крайней мере, тот же объем информации что и при запросе {C}.

Так как это запрос информации об отдельном пользователе, администратор может добавить определенную информации об этом человеке, например: