LINUX.ORG.RU

Клиент-серверное приложение или PostgreSQL всемогущий

 , ,


1

2

1.Задача клиента отправить данные(текст) на сервер.
2.На стороне сервера эти данные записываются в Postgresql, затем обрабатываются и упаковываются скриптом в бинарный файл.
3.Задача клиента получить итоговый файл(бинарный) целым и невредимым.

Какие варианты кошерны на ваш взгляд при решении такой задачи?

Мысль1: скрипт на стороне клиента + psycopg2, на стороне сервера скрипт(который упаковывает данные в файл)+postgre, т.е. данные отправляем и дергаем через psycopg2.

Мысль2: писать клиент-серверное приложение на сокетах. Соответственно через сокет и отправлять данные.

Хочется красивое решение, чтоб душа радовалась :)

Только на сокетах, с ручной обработкой прерываний и поллингом.

anonymous
()
Ответ на: комментарий от BedNuzFany

взять bottle.py

написать ОДИН роут, куда принимать данные, скажем, через post

что-то типа

@post('/data') def post_it(): ....outfile = my_pg_function(request.forms.mypostfield) ....response.content_type = 'application/octet-stream' ....return outfile

данные загонять хоть курлом, хоть вгетом

buratino ★★★★★
()
Ответ на: комментарий от buratino

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

BedNuzFany
() автор топика
Ответ на: комментарий от buratino

Спасибо за комменты,а может есть какие-либо другие варианты? Во-первых, не увидел поддержки postgre от bottle Во-вторых, меня смущает что bottle все-таки веб-framework (микро) В-третьих, кажется есть какое-то другое решение :)

BedNuzFany
() автор топика
Ответ на: комментарий от buratino

Проще и не надо. Надежность, масштабируемость если будет-очень хорошо будет. Вообщем как это качественно сделать, не на коленке..поделитесь мыслями господа.

BedNuzFany
() автор топика

Сделаю на LispWorks Enterprise 64 bit. Цена вопроса — $5000.

Oxdeadbeef ★★★
()

Может кто-то может раскритиковать схему взаимодействия обменa данными через адаптер psycopg2 к удаленному серверу PostgreSQL.
При условии что:
1.Инет у клиента будет 3G(не факт что стабильный)
2.На сервере будет открыт порт для PostgreSQL
3.Объем данных для передачи порядка 100Кб (раз в час)

Может есть какие-то нюансы при данной схеме, поделитесь пожалуйста опытом.

BedNuzFany
() автор топика
Ответ на: комментарий от BedNuzFany

Может есть какие-то нюансы при данной схеме

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

anonymous
()
Ответ на: комментарий от BedNuzFany

1.Инет у клиента будет 3G(не факт что стабильный)

Дорогой, да тебе сам Аллах велел использовать HTTP

2.На сервере будет открыт порт для PostgreSQL

Постгря голой жопой в интернеты? Хм. Не уверен, что это считается её основным юзкейсом.

Manhunt ★★★★★
()

Погуглил вообщем.
Почему бы не использовать RabbitMQ(очередь сообщений)-гарантированная доставка, поддержка ssl, можно использовать в python (pika), горизонтально очень масштабируется.

Мысль3: клиент отправляет данные в очередь к «кролику» (ssl), worker на сервере обрабатывает данные и передает в ответ бинарные данные(файлик) опять же через «кролика».

Вот такой вариантик склеился, что скажете?

BedNuzFany
() автор топика
Ответ на: комментарий от BedNuzFany

Тогда тебе придётся кролика выставлять в инет, а это очень плохая идея. Кроме того, я сомневаюсь, что ты сможешь отдебажить эрланговские приколы.

Не парь людям мозг и делай взаимодействие клиента и сервера через хттп.

leave ★★★★★
()
Ответ на: комментарий от x3al

Интересно, считается ли это за спам?

Это публичная оферта. Которая противоречит законодательству РФ, которое гласит, что на территории России обязательным к приему платежным средством является рубль (ст. 75 Конституции РФ). Предлагаю забанить автора этой незаконной оферты.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.