Вопрос по нагрузке клиент/серверных программ.

[stonix]

Задумал тут сделать нечто напоминающее ICQ, MSN и другие мессенджеры. Точнее даже не сделать, а заказать;)

Не могли бы гуру данного раздела проконсультировать меня?

мне важно понять несколько вопросов:

1.TCP/IP?
2.Как лучше сделать архитектуру моей сети? какая архитектура сети ICQ? ну то есть может кто то знает сколько там серваков, как данные между клиентами и сервером гоняются и т.д. ссылки будут в тему:)
3.Как выдержать общение 5 000 000 человек на сервере? Может как то сам сервер хитро делать или делать сразу несколько серверов? Пользователи например будут получать новости с сайта, не завалят они серверную часть(софт)?
4.может посоветуете что то в дорогу, пару советов?:)

за все большое спасибо.

сразу говорю я в клиент/серверных направлениях пока не силен,
но делфи и принципы разработки знаю немного:)

работу в этом раздеде не предлогать

[Квэнди]

1. Фсат, UDP (какой смысл нагружать сеть избыточностью, если передается не критичная информация)
2. Сервер и один справится ( упаси бог от Win)
3 Не должно возникнуть турдностей, если не держать соединение, а делать его перманентным
4. Читать объявление раздела и RFC

[Квэнди]

Поясню поподробней:
Мирабилис перешел на TCP по причине нестабильности каналов: когда у вас распределенная система и далеко не всех хзорошие стабильные каналы нужно принимать во внимание избыточность информации. Но они с этим переборщили и контроль доставки, реализованный в их библотеки (назачем надо было уходить от идеологии стека TCP и писать свой алгоритм избыточности и контроля доставки не знаю и не могу понять). Что мы получили в результате :
1. Увеличение трафика (да, сейчас это не критично, но факт)
2. То, к чему они стремились переходом на TCP (в частности стабильность сессий) в результате стало их проигрышом:
-В первой версии протокла под TCP отсутствовала понятие безопасности сессии, а так как TCP- time out дотсаточно велик, увести информацию из этой сессии было элементарно.
- В современных версиях протокола безопасность сессии обеспечивается отдельно библиотекой, что собственно привело к меньшей стабильности канала.

В результате мы не получили разницы, а из- за их алгоритма изьыточности получили меньшую стабильность.
Выводы:

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