У меня есть, но как-то воплотить её не так уж легко. Суть: выбираем файл. Берем с него инфу: размер имя. Делим на пакетики по 1,5 Kb(так нужно). И шлем их по очереди. Как только один доходит до пункта назначения, последний рапортует типа: пакет пришел давай следующий. Отправитель шлёт следующий и так до тех пор пока весь файл не перешлем. 
       Вроде легко, но на практике не очень. Может есть более легкая схема? Подскажите плиз))

Ничего сложного в этой схеме я не вижу, стандартная схема пересылки файлов. С чем проблемы возникли?

Да в общем проблемы решаемы, и я их решаю, просто отлаживать долго и много. Вот и хотел спросить: есть ли что полегче) Ну да ладно. Еще вопрос есть:
Если я хочу передать например 3 МБ. Можно ли мне в send() указать размер буфера скажем этих же 3 МБ? Отправится ли пакет такой величины? И если да, то как мне его принимать? Ведь он же придет на комп приемник по частям. Подскажите.

Есть ли ограничения на размер посылаемых данных в send() я не знаю, никогда над этим вопросом не задумывался  . Скорее всего зависит от архитектуры. Под windows я видел примеры посылки больших файлов в send. Никто посылать пакет размером 3MB не будет, весь буфер будет разбит на маленькие пакеты.

Такой способ посылки лучше не использовать.



Ну и принимай по частям.

Это сообщение отредактировал(а) ptr - 30.10.2006, 10:46

Надо хорошо себе представлять, что делает send().
Вы указываете буфер любого размера - send() передает содержание этого буфера в буфер передачи модуля TCP. Размер этого буфера тоже в принципе можно устанавливать с помощью опции SO_SNDBUF функции setsockopt().
Но в сеть все равно будут уходить IP-пакеты, содержащие не более 1460 байт данных, так как для Эзернета MTU равно 1500 байт.
Поэтому на send() программа будет висеть до тех пор, пока все вот так поэтапно не передастся на тот конец - если не сделать сокет неблокирующим или применить асинхронную функцию WSASend()
Насчет принимать - беспокоиться не стоит - на той стороне будут висеть на recv() до тех пор, пока не придет сегмент FIN, означающий конец предачи, и recv() вернет при этом 0.

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

Всё зависит от задачи. Если, например, закончилось место на диске или что-нибудь другое случилось, то лучше передавать серверу/клиенту об ошибке. Иногда это проще сделать именно так, как было сказано.