Реализация небольшого асинхронного сервера

[anight]

Если клиент обрывает соединение — сервер падает:

> ./pypi.py
new client from 127.0.0.1:56071
client dropped connection
warning: unhandled close event
Client error: [Errno 9] Bad file descriptor
Traceback (most recent call last):
  File "/local/python/lib/python2.6/asyncore.py", line 105, in readwrite
    obj.handle_close()
  File "/local/python/lib/python2.6/asyncore.py", line 491, in handle_close
    self.close()
  File "./pypi.py", line 160, in close
    self.server.removeClient(self)
  File "./pypi.py", line 123, in removeClient
    del self[client.fileno()]
  File "<string>", line 1, in fileno
  File "/local/python/lib/python2.6/socket.py", line 165, in _dummy
    raise error(EBADF, 'Bad file descriptor')
error: [Errno 9] Bad file descriptor

[tom]

Что-то у меня не получается воспроизвести ошибку. Вы через телнет подключаетесь? Как закрываете соединение?

[anight]

В telnet — ctrl+], «quit», enter. Linux. Воспроизводится стабильно.
Python 2.6 — может в версии дело?

[tom]

Действительно, проверил на 2.6 версии — такая же ошибка. Получилось исправить добавив пустой метод handle_close(self): pass. В версии 2.5 у меня вызывается handle_expt при такой ошибке, а до handle_close дело не доходит. Вероятно, разработчики что-то пересмотрели.

[Vetal4eg]

Оперативно! Вам бы суппорте работать (:

[tom]

Зачем, для этого есть замечательная asyncore :)
Или что вы понимаете под «диспетчиньем»?

[tom]

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

[BigAlex]

А почему не на Twisted? Есть ли какие-то примущества в реализации на голых сокетах?

[smartly]

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

[tom]

На твистеде я пишу в настоящее время довольно замудренный REST-сервис, впечатления исключительно положительные. Можно сказать, что он меня и натолкнул на мысль написания этого маленького сервиса. Только здесь я решил воспользоваться возможностями, встроенными в язык, без лишних усложнений.

[BigAlex]

И все же, интереса ради, для production рекомендуете Twisted? Простота разработки, надежность, etc?

[tom]

Простота разработки приходит только после определенного опыта, потому что фреймворк все-таки оправдывает свое название :)
А архитектурно и по производительности он меня целиком устраивает, когда привыкнешь к идеологии становится очень комфортно с ним работать.

[vseloved]

если это сервер, то как его остановить? ;)

[tom]

Т.к. это учебный сервер, достаточно нажать ^C :)

[vseloved]

а зачем учить плохому? ;)
(я этот тред затеял к тому, что обработка вызовов — далеко не самая морочливая и сложная задача, которая возникает при разработке серверов. Гораздо больше возьни с запуском/остановкой, контекстами и т.п. вещами — вот об этом и интересно было бы почитать.
sidenote: Тут, например, может помочь библиотека python-daemon, однако и она решает только часть проблем)

[tom]

Все это во многом зависит от задач, накладываемых на сервер, поэтому и волшебной таблетки нет. Хотя я как-то и не сталкивался с особыми проблемами при старте/остановке.

[vseloved]

а в чем, по вашему, заключается особая специфичность в зависимости от задач?

[tom]

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

[vseloved]

и что, это никак нельзя обобщить? ресурсы сервера — это обычно дескрипторы (файлов, сокетов) — методы работы с ними стандартны. А какие еще ресурсы вы имеете в виду?

[tom]

Я имею в виду кэш для прокси-сервера, базу данных для сервера отчетов, спул-директорию для сервера печати.

[vseloved]

вы простите, конечно, мое занудство, но что будет делать при остановке прокси-сервер с кешем, сервер отчетов с БД, а сервер печати со спул-директорией?

[tom]

Да все что угодно, в том то и дело :) Сжимать кэш, ждать отключения клиентов, и т.д.

А если под стартом/остановкой вы имели в виду просто отключение от терминала, форк в фон и прочие мелочи, то я не вижу в этом никаких подводных камней. Есть ли они?

[vseloved]

да, именно это.
Оказывается есть (почитайте rationale к тому же python-daemon). Особенно проявляются в связи с остановом, особенно когда начинаем иметь дело с потоками (например, попробуйте ка убить thread)