Передача файлов по сети.

ftp
nfs

Имеется в виду транспорт или софтина которая умеет раз в 3 сек слать файл?

hint: если что, то софтина - это cron :)

да мало ли, rsync, ftp/sftp, rcp/scp и иже с ними.в конец концов нарисовать собственную системку с минимальным оверхедом за пару часов.

// wbr

В конце-концов, заведи на сервере Базу Данных и укладывай текстовую информацию в неё... И обрабатывать будешь легче и надёжнее (не будешь периодически "ловить" сервером "пустышки").

subversion не подойдет?

nc + tar, scp, lftp

>> В конце-концов, заведи на сервере Базу Данных

ОверГолова

++
тут вообще всё что хочеш можно пользовать.
bash, cron, ftp/всёподобное, 15мин работы.

> В конце-концов, заведи на сервере Базу Данных и укладывай текстовую информацию в неё...

Mad overengineering skills detected.

> Mad overengineering skills detected.

:-)

А ты _сделай_ выкладывание файлика раз в 3 сек и считывание содержимого этого файлика каждые 3 сек. Погоняй с часик, проконтролируй побайтно, что было считано, на самом деле. Может, и поймёшь, "в чём прикол" и зачем нужны механизмы Баз Данных...

echo "${data}" | netcat ${ip} ${port}

Дальшее обьяснять?

> echo "${data}" | netcat ${ip} ${port}

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

> Дальшее обьяснять?

Об этом лучше спросить автора топика, можно ли в его серверный процесс встроить нормальную/полную обработку этого соединения и "бесфайловую" синхронную передачу данных. Мне идея понятна. Главное же не дать возможности основному серверному процессу считать недоформированный файл, в середине или начале процесса его формирования, не так ли?

P.S. Тем не менее, IMHO работа с БД выглядит менее затратной, т.к. не нужно будет писать свой сервер, свои реализации её механизмов по обеспечению целостности данных.

:-)

Целостность данных можно по md4 проверить (md4 довольна быстра и не накладна)

Просто у меня была ситцуация когда надобыло полный дамп харда передать с проверкой на целостность передачи. Было поднята pxe система которая читала определнное количество данных (у меня было 32мб), делала контрольную сумму, отправляла ее на хранилище, потом отправляла данные. Скрипт не очень большим оказался и по сути свелся к -e опции на сервере и последовательному read данных.

Просто при небольшом количестве клиентов и необходимости что-то сделать быстро я считаю netcat лучшем решением

Проблема не в передаче файла, тот же scp прекрасно справляется с задачей. Проблема с квантованием процесса формирования файла: заголовок, таймаут, порция данных, таймаут, порция данных, таймаут, ... , закрытие файла. Основной процесс обработки может асинхронно начать считывать файл в любой из этих периодов и закончить чтение, дойдя до конца недоформированного файла, по существу, неполных данных. Это не проблема сети, это проблема синхронизации процессов.

:-)

>> Проблема не в передаче файла, тот же scp прекрасно справляется с задачей. Проблема с квантованием процесса формирования файла: заголовок, таймаут, порция данных, таймаут, порция данных, таймаут, ... , закрытие файла. Основной процесс обработки может асинхронно начать считывать файл в любой из этих периодов и закончить чтение, дойдя до конца недоформированного файла, по существу, неполных данных. Это не проблема сети, это проблема синхронизации процессов.

+1

И кстати netcat (в режиме сервера) держит только одно соединение одновременно. И если нужно отправлять файлы на сервер с нескольких машин, то решение с nc не подходит однозначно.