anonymous@RULINUX.NET~# | Last login: 2024-11-22 21:12:53 |
Регистрация Вход | Новости | Разметка | Пользователи | Галерея | Форум | Статьи | Неподтвержденное | Трекер | Правила форума | F.A.Q. | Ссылки | Поиск |
Форум - Development | [RSS] |
Есть десктопная программка, клиент-серверная архитектура, но на сервере ничего особенного нет. По сути - морда для удалённой работы с БД и кучка серверных скриптов. Клиентская часть посылает SQL запросы и получает результат, авторизация выполняется силами БД.
Но, кроме данных в БД, есть ещё файлы, в данном случае - изображения. В базе сохраняются пути к файлам, ну а клиент их должен как-то забирать и отображать. Сейчас всё это счастье делается через FTP. В принципе работает, хотя насчёт самого протокола есть сомнения.
Во-первых - он не очень безопасный, как пишут в интернете. Картинки, конечно, не бог весть какие важные, да и сервер сидит в локальной сети за NAT-ом, но всё равно, мало ли что в будущем будет. Во-вторых - разделение прав, допустим на чтение и запись, реализуется через классические юниксовые методы, пользователи и группы. Выглядит немного кривовато, да и простора для модернизации уже нет. Вот, собственно, и вопрос: а что бы такое вместо FTP сделать?
Из рассматриваемых вариантов:
1. HTTP. Воткнуть вебсервер, показывать картинки через него, в качестве аутентификации сделать либо HTTP basic auth (или как она там зовётся), или можно в будущем сделать простую программу, которая будет раздавать картинки на основе данных из БД и какой-нибудь логики. С другой стороны - а лучше ли оно будет, чем FTP?
2. WebDAV. Никогда с ним не работал, но, говорят, для такого подходит.
3. Хранить картинки в базе в виде блобов, так тоже кто-то делает. Меня это немного смущает, да и требований "сделать всё через БД" нет. Насчёт производительности тоже есть сомнения.
Кто-нибудь знает красивые и удобные способы для решения этой задачи?
SystemV(*) (2011-07-29 22:20:00)
Emacs-w3m/1.4.414 w3m/0.5.3
|
|
|
Скрыть
Re: Способ передачи изображений по сети>Я за первый вариант, если картинки большие - то тянуть в несколько потоков. Недостаток: клиенту потребуется два протокола - к базе и веб-серверу.
>Ещё бы интерфейс клиента к БД завернуть через HTTP, возможно с переносом части логики на сервер.
|
Скрыть
Re: Способ передачи изображений по сетиблоб будет сильно нагружать базу, но имеет свои преимущества. Если большой нагрузки не планируется, то довольно удобно. ФТП сам по себе совершенно безопасен. Опасны бажные проги и криворукие одмины. Да и смешно заботиться о безопасности, если SQL-запросы посылает удалённый клиент. Выбор между ФТП и ХТТП - ерунда, сделай как попало. Какой-нибудь тайнихттпд будет не хуже фтпд, а с точки зрения возможной расширяемости - лучше. Потом можно будет вынести часть бизнес-логики на веб-сервер с перспективой поставить опач или томкат не меняя клиентскую часть. про вебдав не ведаю. Почитай его описание для начала чтоли |
Скрыть
Re: Способ передачи изображений по сети> а в http это всё как-то криво реализуется
|
Скрыть
Re: Способ передачи изображений по сети> два протокола есть и сейчас, так как ftp, так что я ничего не потеряю.
> Тоже возникала такая мысль. Правда там есть вопросы, т.к. сервер иногда должен оповещать клиента (например об обновлении базы, или ещё о чём-нибудь), а в http это всё как-то криво реализуется, всякие long-polling и недоделанные вебсокеты.
А так.. Поставишь какой-нибудь похапэшный акселератор с кешиком. В кешике сохраняешь значение когда в последний раз произошло событие такое-то. Пришешь одну функцию на похапэ которая берёт из кешика это значение и отдаёт клиенту с заголовками чтобы проксики это кешировали не дольше 1й секунды . Стопицот клиентов ежесекундно опрашивают сервер по адресу http://yuorserver.narod.ru/server.php?isEventHappened и им либо проксик отдаёт результат либо сам сервер, но при этом не особо нагружаясь (можно даже дату не парсить на каждый запрос - сложить в кеше же текст ответа и плювать им в клиентов) Остальные запросы в базу тоже можно представить в виде вызовов скрипта, который будет возвращать XML или JSON клиенту. Потом к этому и вебдванольную морду можно будет приделать.. |
Скрыть
Re: Способ передачи изображений по сети> на самом деле не совсем. Через аякс вполне смотрибельно, если коиент по таймауту опрашивает. В чём-то лучше, чем постоянное сокетное соединение - отвалившийся клиент не будет держать мёртвый коннекшн.
|
Скрыть
Re: Способ передачи изображений по сети>Да и смешно заботиться о безопасности, если SQL-запросы посылает удалённый клиент.
>Выбор между ФТП и ХТТП - ерунда, сделай как попало.
|
Скрыть
Re: Способ передачи изображений по сети>Да со всех сторон лучше - а что если таких клиентов стопицот? На каждого коннекшен держать задолбаешься.
|
Скрыть
Re: Способ передачи изображений по сетиТред не читал, но думаю надо все выпилить, БД тоже и забирать картинки и данные (хранимые в файлах) по sftp, а данные сжимать в блобы и криптовать GPG, на dm-crypt разделе только с twofish-x-x, при этом производить смену всех ключей каждый месяц. Вот это будет красиво. anonymous(*)(2011-08-01 18:52:07)
Mozilla/5.0 (X11; U; Linux i686; ru; rv:1.9.1.19) Gecko/20110701 Iceweasel/3.5.19 (like Firefox/3.5.19) |
Скрыть
Re: Способ передачи изображений по сетижесть! и керберосом его, керберосом как комаров фумитоксиком |
|
|
|
Этот тред читают 1 пользователь: |
Анонимных: 1 Зарегистрированных: 0 |
Re: Способ передачи изображений по сети
Я за первый вариант, если картинки большие - то тянуть в несколько потоков. Недостаток: клиенту потребуется два протокола - к базе и веб-серверу. Ещё бы интерфейс клиента к БД завернуть через HTTP, возможно с переносом части логики на сервер.