|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Nick Leuta 2:5020/400 10 May 2003 16:16:59
To : Alex Semenyaka
Subject : Re: обработка OOB
--------------------------------------------------------------------------------
"Alex Semenyaka" <Alex.Semenyaka@f640.n461.z2.fidonet.org> сообщил/сообщила
в новостях следующее:
> Hello Nick.
> 27 Apr 03 02:45, you wrote to all:
> NL> if (recvurg)
> NL> goto got_oob;
> NL> static void
> NL> sigurg(int signo)
> NL> {
> NL> recvurg = 1;
> NL> }
> NL> В итоге передача данных, насколько я понял, прервется при любой
> NL> активности на управляющем соединении.
> Сорри, в код не полез, но неужно по управляющему соединению всё ходит в
виде
> OOB? Крайне сомнительно. По-видимому, авторы полагают, что приход
oob-данных -
> достаточное событие для срочного разрыва соединения (иначе кой чёрт они
oob?).
Hе все. И действительно срочные события но не факт, что из-за них надо рвать
соединения. Поясню ситуацию. По приходу на управляющем соединении OOB
посылается сигнал, что позволяет приложению не проверять постоянно факт
наличия доступных для чтения данных на этом соединении в цикле или еще как,
но реагировать на них только в 1. случае их наличия 2. и в случае их
важности, если такое событие вдруг произойдет (так собственно ftpd и делал
до того, как у него это привели в соответствие с OpenBSDшным), занимаясь при
этом другими делами, например, передачей данных на _другом_ соединении.
Короче говоря, это позволяет однопоточному приложению, работающему в данный
момент на одном сокете, реагировать на события на другом сокете.
Многопоточному в этом смысле проще.
А вот какое именно сообщение послано в качестве OOB, и как на него
реагировать - это совсем другой вопрос. Команда ABOR должна прервать
соединение, STAT - просто выдать статистику о количестве переданного на
данный момент.
> NL> В принципе, легко исправить, вернув обратно myoob() роль обработчика
> NL> SIGURG, как это и было изначально, только вот непонятно, зачем было
> NL> огород-то городить (разве для того, чтобы было одинаково с OpenBSD -
> NL> там то же самое)?
> Обработку сигнала лучше сделать максимально компактной. Лучше и проще
всего -
> выставить флаг, который проверить в безопасном месте. Опять же, если не
> вдаваться в специфику, общее впечатление - что люди следуют этому
принципу.
> Почему - из-за реальных граблей или просто безопасное программирование -
> навскидку не скажешь, а у меня голова уже не варит сегодня :)
Hу, с этим никто и не спорит, и у них в логах CVS написано почему они на это
пошли. И не все так страшно - может проверять флаги оказалось действительно
лучше, чем выкапывать ошибки в старой системе обработки сигналов.
HО я-то обратил внимание на то, что обрыв соединения для передачи данных
просто по факту прихода OOB - противоречит _логике_ работы ftpd, заложенной
в RFC959 и старом коде. OOB - это способ сообщить приложению о том, что
пришло какое-то важное сообщение. Во время передачи данных допустим приход
двух сообщений - команды ABOR и команды STAT. Какой должна быть реакция на
них я сказал выше.
--
* Паранойя - профессиональное заболевание системных администраторов...
SkyNick
--- ifmail v.2.15dev5
* Origin: Demos online service (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
