Winsock Transmit File
Как это будет удобнее сделать? Меньше мороки?
Знаю есть функция Transmit File на передающей стороне, а на принимающей должна стоять обычная recv? Reсv способна принять файл, например, размером 5мб, если я его посылаю тарансмитом?
Или там надо будет реализовать "умный" прием?
На каком языке программирования Вы реализуете данный функционал?
передать то передадут. только вот что вы понимаете под контролем целостности? если то, что recv & send гарантируют прием/передачу всех данных, что вы послали - то нет, это неверно.
Вообще-то гарантируют, на то он и TCP, чтобы контролировать дошла ли порция данных до другого узла и отправлять потерянный пакет еще раз. Еще раз повтарюсь речь идет о TCP сокете. Дейтаграммные сокеты такого не гарантируют.
Конечно вероятность что что-то дойдет в искаженном виде есть, т.к. контроль осуществляеться по средствам CRC, но вероятность эта крайне мала.
далее. автора интересует передача файла. как я писал -
recv - вполне способна прочитать меньше байт чем послал send или больше. это особенности реализации TCP. поэтому - если мы пересылаем данные, надо самостоятельно реализовывать контроль за принимаемым потоком данных.
Я прекрасно знаю как работает TCP. Если сервер повиснет, то клиент повисит и произойдет разеъдинение по таймауту. revc и send об этом уведомляют прекрасно и бояться нечего.
далее. автора интересует передача файла. как я писал -
recv - вполне способна прочитать меньше байт чем послал send или больше. это особенности реализации TCP. поэтому - если мы пересылаем данные, надо самостоятельно реализовывать контроль за принимаемым потоком данных.
Ну если речь об этом, то согласен. send добавляет данные в буффер, который потом по кусочкам отправляеться на другую сторону, recv работает аналогично у принимающей стороны. Поэтому одна порция данных, отправленная send'ом, может стать двумя для recv. Решение простое - в цикле принимать сколько примится и добавлять к буферу, или сразу писать в файл. В нем же проверять на дисконнект.
ну я говорю не про зависание, а про падение сервера. и моментальный перезапуск. при котором не происходит отправки FIN. клиент просто не узнает о падении и будет слать по уже несуществующему коннекту пакеты, до получения RST.
Ну если речь об этом, то согласен. send добавляет данные в буффер, который потом по кусочкам отправляеться на другую сторону, recv работает аналогично у принимающей стороны. Поэтому одна порция данных, отправленная send'ом, может стать двумя для recv. Решение простое - в цикле принимать сколько примится и добавлять к буферу, или сразу писать в файл. В нем же проверять на дисконнект.
решение - либо посылать вместе с пакетом размер переданного буфера - как часть данных, и на приеме вытягивать этот размер и читать данные до получения всего что послано (как делает BIND, например), либо использовать функции, которые самостоятельно разбивают данные на строки (типа fgets)
