Способы передачи файлов по сети. Кроссплатформенно.

[Brainenjii]

http://pastebin.com/eUzgHrRc - комментарии к серверу
http://pastebin.com/PjHqQfYN - комментарии к клиенту
ГЗВ: не надо никаких компонент... просто скомпильте два исходника (создайте проект как программу(program), а не как приложение(application)) и второй (клиент) запустить как <clientname> PUT /path/to/file.
UPD2: на Windows не проверялось...но если файл лежит рядом с бинарником - проблем быть не должно...

[veresk]

Так ты их консольными набабахал, вот оно чо..

[B4rr4cuda]

Я буду неожиданно банальным, но почему не сделать небольшой вебсервер, который будет отдавать файлы?
Берем synapse и его пример http сервера, правим функцию ProcessHttpRequest, в самое начало которой вставляем что-то подобное:

Код: Выделить всё

if (request = 'GET') then begin
    vWebPath:=FWebPath+ReplaceString(uri,'/',PathDelim);

    AddLog('GET:'+vWebPath);

    if FileExists(vWebPath) then begin
      fs:=TFileStream.Create(vWebPath,fmOpenRead);
      try
        OutputData.LoadFromStream(fs);
        result := 200;
      finally
        FreeAndNil(fs);
      end;
    end else result := 404;

  end;

[alexey38]

Когда требуются такие простые действия, как передача файла, то низкоуровневые технологии (сокеты) бывают проще, чем нагромождение высокоуровневых. FTP, HTTP - нужно, если нужна работа через инет. Расшаренные папки (типа самбы) - это не ради одного файла. Если в рамках системы есть файловый сервер, то можно его использовать, если нет, то городить не зачем. SQL сервер - это СУБД, для работы со структурированными данными, но никак не ради бинарников.

Работа с сокетами простая. Нюансы можно смотреть на форумах, или смотреть исходники компонентов их использующих.

[vitaly_l]

Когда требуются такие простые действия, как передача файла, то низкоуровневые технологии (сокеты) бывают проще, чем нагромождение высокоуровневых.

А в чём разница??? Что там, что здесь - файлы передаются одинаково, частями... B4rr4cuda - предлагает более оптимальный вариант...

[B4rr4cuda]

Когда требуются такие простые действия, как передача файла, то низкоуровневые технологии (сокеты) бывают проще, чем нагромождение высокоуровневых.

Смотря какая задача.. у нас недавно задача была сделать систему автообновления для комплекса программ, мои коллеги, ответственные за проект тоже решили использовать "низкоуровневые технологии".. в результате они наваяли велосипед, создали целый протокол взаимодействия и потом огребли проблем при сопровождении.. Им пришлось поддерживать версионность самого протокола, ибо вылезали проблемы при взаимодействии, получили гемморой в разработке и сделали в результате некий аналог вебсервера..
К чему я веду - если задача простая - передача одного файла, то вебсервер не имеет смысла.. Если же планируется более сложное взаимодействие - то почему бы и нет? Протоколы отлаженые, методики проверенные..

[alexey38]

А в чём разница??? Что там, что здесь - файлы передаются одинаково, частями... B4rr4cuda - предлагает более оптимальный вариант...

Любые технологии передачи по сети используют сокеты.

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

[vitaly_l]

Сомневаюсь, что в задаче будет ежесекундный обмен файлами по 700Мб... Соответственно B4rr4cuda - предложил более оптимальное и надёжное (проверенное) решение, которое вернёт HTTP-500. (Хотя на самом деле - без разницы...)

[B4rr4cuda]

Если решение корпоративное, то смена внутреннего протокола, это не проблема, перекомпилировать клиента и сервера и разом заменить все программы.

Вот в разовой замене всех программ обычно и начинается затык)) Особливо, если это сеть филиалов, расположенных в разных городах, в разных часовых поясах (что ведет к различным рабочим часам).. В подобной ситуации смена внутреннего протокола - это не просто проблема, это просто праздник геммороя, какой-то. Потому и нужна либо обратная совместимость протокола, либо использование уже отлаженного..

[alexs]

Если решение корпоративное, то смена внутреннего протокола, это не проблема, перекомпилировать клиента и сервера и разом заменить все программы.

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

[vitaly_l]

Не надо изобретать велосипеды (в самом плохом смысле слова) там, где есть хорошо отлаженные решения.

Не согласен. т.к. велосипеды - нужно изобретать всегда и везде... иначе изобреталка заржавеет... Посему: Согласитесь что, Сокеты, это как и HTTP,FTP итп - тоже, хорошо отлаженные решения и их естественно достаточно для обмена файлами т.к. это база для HTTP и FTP...
Нет безапелляционных аргументов в пользу: FTP или HTTP или сокетов... Поэтому без разницы, что использовать т.к. скорость передачи одинакова. Однако: протоколы... - перевешивают в сторону HTTP и FTP.

[Mr.Smart]

vitaly_l бред :facepalm:

[vitaly_l]

facepalm

Бред... facepalm... Я художник - мне можно...

Истина в аргументах... Мои аргументы взяты из ответов в данном топике...
Одни говорят: хорошо, то что слева, другие говорят, хорошо то, что справа...
Я говорю, что без разницы... т.к. результат идентичен, но соглашаюсь что, ЛУЧШЕ - использовать более проверенные решения.
Бред? facepalm?


.

[Ism]

Вообще я не понимаю, в чем прикол. Сделайте все через ftp, а легко настраиваемых ftp серверов много. Программе клиенту должно быть все равно. Если вы хотите шифровать, то с сокетами будет большой геморрой. Зато многие ftp сервера работают по sftp
Кроме того есть OpenSSH , он тоже умеет передавать файлы. Для общения по sftp подойдет curl и wget (правда не проверял), они компактны и их можно впихнуть в дистрибутив клиента

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

http://www.nulled.cc/threads/150554/

Добавлено спустя 6 минут 54 секунды:
http://spiritus.external.vkontakte.anti ... st/133703/

Добавлено спустя 1 минуту 25 секунд:
Авторизация на сайтах из bash с помощью curl
http://blog.elve.name/?p=104

Все это кроссплатформенно

http://curl.haxx.se/download.html

[vitaly_l]

чтоб программа сама была сервером с точки зрения антивируса опасно

А в чём опасность, если сервер программа??? и какая разница?! (по мне, так: любой сервер - программа...)
(в остальном - это третье решение, задачи и все идентичны...)