сабж. интерсует написание многопользовательского онлайн-покера.
скачивается клиентская программа на ПК пользователя и он играет с другими игроками через инет.

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

Ууу, как все запущено. 
Тут много технологий будет использоваться.
Если например я бы делал подобную игру, то мне нужно было бы следующее:
* язык для клиентской части (в моем случае платформа .NET и язык C#)
* передача данных допустим через протокол на XML или в бинарном виде
   естественно через TCP/IP
* серверная часть допустим на ASP.NET или PHP (это например для протокола на основе XML)
   также может использоваться свой сервер на C++, C# и т.п.
* база данных на сервере MS SQL или MySQL

Может конечно я что-то и пропустил, т.к. привел только все высокоуровневые элементы.

хм. при чем тут платформы. 
я говрю о технологиях обена данными. схеме.
пока что вижу это как flash клиент, php сервер
работа через сокеты.
вот о технолонии обмена советы велком))
например, на примеры кода какой-нить игры или чата на сокетах или еще  чем.

В каждом конкретном случае реализация обмена данными будет своя. Придумать что-то усреднённое и универсальное, имхо невозможно, т.к. конкретное наполнение всегда будет требовать свои специфичные возможности, и протокол обмена будет очень сильно привязан к возможностям приложения, его использующего. Можно взять какую-то устоявшуюся технологию, и развивать её в рамках своего приложения. К примеру, если речь идёт о клиент-серверном гетерогенном приложении (php и flash соприкасаются очень мало), то можно использовать схему "клиент - сервер с объектами, живущими на сервере", т.е. flash-клиент использует php-сервер опираясь на сессию, инициируемую входом по логину и паролю, а сервер использует известный паттерн "database based session" для хранения общей информации о соединении с клиентом в БД, таким образом даже через N минут бездействия конкретный flash-клиент сможет общаться с сервером, если есть предыдущие обращения к серверу. Если же речь идёт об используемых библиотеках, тут разговор будет совсем о другом. С какой стороны нужно общее решение ? Со стороны flash клиента ? Один набор библиотек, общих подходов и т.п., и всё будет об Action Script. Со стороны сервера ? Стандартные PEAR-библиотеки, драйверы для баз данных и т.п. специфичные для php вещи. Резюмирую, для того чтобы получить конкретный ответ, придётся углубиться в детали вашего приложения.

Каждая платформа просто предлагает свои пути упрощения работы клиент-серверных приложений. Сокеты - это наиболее "системный", низкий уровень. Он не всегда бывает нужным. 
mr.DUDA уже сказал, что все зависит от возможностей приложений. Их в большинстве случаев и определяет используемая платформа. Например, если у тебя пхп или другая аналогичная серверная технология, то ты не сможешь пользоваться сокетами. Здесь приложение будет просто отдавать клиенту необходимую информацию по протоколу HTTP. Соответственно не имеет смысла на клиенте (например на C++, Delphi, да и .NET) реализовывать свой класс для работы с сокетами и т.п., поскольку для HTTP-запроса существуют уже готовые решения. Аналогично и в Flash. Он тоже расчитан на HTTP-запросы с получением данных в формате XML (поскольку его достаточно просто генерировать на серверных платформах).
А в полной мере сделать приложение с сокетами (а писать придется и клиент, и сервер) тебе будет сложно. Тем более, что использовать серверную часть ИМХО ты сможешь лишь при работе в локалке. Чтобы установить подобное приложение в интернете, понадобится (виртуальный) выделенный сервер. Аренда достаточно дорого стоит, кроме того, тебе придется администрировать его самим. А большинство серверов работают под *nix, поэтому необходимо знать соответствующую тему и уметь программировать под nix-платформу.