Вообще использовал я TServerSocket/TClientSocket компоненты. Но вроде народ говорит, что устарели они уже.
Подумал о переходе на Indy компоненты, но и тут говорят, что кривые они, новые версии не совместимы со старыми и непонятно вообще как там будет с совместимостью у последующих версий.

Вообще под какие проекты ищутся компоненты.

1. Первый проект - чат. Запускается сервер, подключаются клиенты, через сервер идёт общение (подобно ICQ, только многопользовательский режим, т.е. не один-на-один).

2. Второй проект. По типу RAdmin'a система вещания "скриншотов". На одном компе запускается прога передающая "скриншоты" (пожатые есстественно), на ДРУГИХ проги разжимающие потоковую инфу и отображающие.
Т.е. что-то типа проектора, вещающего на удалённые мониторы. Скорее всего в локальной сети. Для Интернет это всё же накладно будет.


Что сейчас прогрессивное человечество использует в этом плане?

в каком смысле устарели? плохо пахнут? дум3 не тянут?
скажешь тоже) если тебя эти компоненты устраивают и не нужны навороты индей, то юзай их)

Ну.. эти компоненты "разбивают" пакеты, "склеивают", из-за этого некоторые проблемы, приходится самостоятельно решать. Может быть есть компоненты свободные от этого.
Кстати, а почему эти компоненты не передают блоками? Вместо этого получается какой-то "своеобразный поток"  То несколько пакетов прийдёт с одинаковым содержанием, то ещё чего-то..

www.overbyte.be - ICS

При чём здесь компоненты?
Так работает TCP/IP
Какие бы компоненты не использовались, эту проблему всё равно придётся решать, т.к. работа идёт со стримом, а не с фактом приёма/отправки.
Не устраивает - используй UDP. В этом протоколе отправка идёт пакетами, а не потоком.

Я имел ввиду может это уже решено на "компонентовом" уровне.

Кстати, а какое преищество потока перед пакетами? Где преимущества явно проследить можно?
Если честно слабо понимаю разницу между потоком (TServerSocket например) и высылаемым по одному символу на пакет ( в UDP например ). Не понятно где может использоваться такой стрим когда то и дело слидишь за тем как пакеты разрываются, дублируются.. На это ресурсов по-моему ещё больше уходит 
Какой смысл использования потоков? (может я их использую просто не по назначению..)

Можно ли привести примеры ситуаций в которых важен именно поток?
Попытаюсь самостоятельно: потоковое видео, аудио... Но и тут нужно следить чтобы пакеты не дублировались ведь? Опять не видно здесь преимуществ потока.. Хотя если посмотреть иначе. Что получится если подключить не поток, а пакет и малыми пакетами рассылать то же видео.. насколько понимаю это получится намного "хуже" чем при использовании потоков?
мдя 

Экономия траффика
Непрерывные данные
Данные, конечный размер которых не известен либо поток
Маршрутизация - не все сервера маршрутизируют UDP
Гарантированная доставка
Гарантированная очередность доставки при некорректной маршрутизации
Высокий уровень абстракции
Универсальность
Да и вообще поток более логичен

Да резать нужно. Но этим должен заниматься протокол верхнего уровня.
Разработай протокол, или возьми уже реализованный стандартный.
А дальше уже идёт прозрачное его прикладное использование.
Так и должно быть.
Так и есть правильно.

Snowy, спасибо за развёрнутый ответ, теперь более/менее в голове всё "утряслось".

Извините, что вклиниваюсь.   



Каким образом ч/з TServerSocket/TClientSocket принять и передать данные, размер которых заранее неизвестен? Особенно как при приеме определить, что данные уже все приняты?

Вместе с данными надо посылать их размер

А вот этим должен уже заниматься протокол верхнего уровня.
Как вариант: потоковые данные высылаются небольшими пакетами по мере поступления данных.
У каждого пакета должен быть свой заголовочек, где и указан размер и прочие данные, если таковые имеются.
Второй вариант: перекодировать данные так, чтобы исключить попадания в набор символа-терминатора. Но этот вариант менее популярен.