нити vs неблокирующий сокет

Почему не сделать один сокет и читать, пока нет сообщения о завершении?

зачем два сокета?

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

это фтп на велосипеде что-ли?

обычного poll'а будет за глаза.

да, протокол типа велосипедного фтп, сервер уже скомпилен, исходников нет, так что знаю только протокол и что используются 2 сокета

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

Нафиг надо. Лучше использовать какой-то свой протокол передачи данных, который будет обеспечивать определение конца. К примеру через указание размера передаваемых данных или через терминатор. Или (что ещё лучше) использовать уже готовые протоколы и библиотеки для работы с ними: json-rpc,xml-rpc, etc...

Что лучше применить: нити или сделать второй сокет неблокирующим?

Дело вкуса, как говориться. Правда имхо, лучше всего использовать какой-то один метод. Мешать не стоит, некрасиво будет.
Я бы сделал т ак. Написал-бы две реализации. Одну на блокирующих сокетах и тредах, другую на неблокирующих сокетах. И опыт будет и протестировать можно, что быстрее.

увы, протокол сделан до меня, если сам до этого писал то передавал длину.

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

Нет никакого смысла делать сокет блокирующим, зачем зависать на сокете
нескончаемо, нужно с тайм-аутом

Тут
http://89.108.108.125:8282/client_ftp_public.txt
можете посмотреть простой ftp-клиент.

спасибо

Нет никакого смысла делать сокет блокирующим, зачем зависать на сокете нескончаемо, нужно с тайм-аутом

Так именно на блокирующий сокет и натравливают select() с таймаутом. Если сокет неблокирующий, read()/write() и так сразу возвращаются с -1 и ошибкой EAGAIN/EWOULDBLOCK.