В этой пересмотренной версии метод send_to_all () сервера будет заменен дру­гим. Вместо поиска каждого клиента и отправки ему одноадресного сообщения, содержащего, к примеру, описание Apple iPad Air 2 , выполняется единственный вызов метода send_event() объекта связи с использованием адреса группы многоадресной рассылки в качестве адреса назначения. Более подробно этот метод будет рассмотрен при описании кода.

Рассмотрим пересмотренный протокол интерактивной переписки с точки зрения клиента. В первоначальной версии этой системы клиент обменивался с сервером сообщениями через единственный сокет UDP, назначенный серверу. В новой версии эта схема изменена.

Клиент создает сокет для взаимодействия с сервером. Этот этап остается так же, как и в первоначальном приложении. Для отправки от клиента к серверу всех сообщений применяется один сокет; мы будем называть его управляющим сокетом.

Клиент создает второй сокет для получения многоадресных сообщений. При регистрации клиента сервер отвечает двумя сообщениями. Первое подтверждает успешную регистрацию, а второе содержит номер порта, через который клиент должен принимать многоадресные сообщения. Клиент отвечает на это, создавая второй сокет и привязывая его к указанному порту. Теперь клиент выполняет в цикле функцию select (), ожидая перехода в состояние готовности сокета многоадресной рассылки, а также стандартного устройства ввода и управляющего сокета.

Клиент присоединяется к группам многоадресной рассылки для подключения к каналам. Существует взаимно однозначное соответствие между каналами интерактивной переписки и группами многоадресной рассылки. После того как клиент подключается к новому каналу интерактивной переписки, сервер отвечает подтверждением, содержащим адрес группы многоадресной рассылки, в который передаются общедоступные сообщения для нее. Клиент присоединяется к группе с использованием метода mcast_add().

Клиент выходит из группы многоадресной рассылки для отключения от канала. Что бы отключиться от канала, клиент вызывает метод mcast_drop ().