Программирование сокетов на C - PullRequest
1 голос
/ 07 июня 2011

Более одного клиентского процесса отправляет сообщения на сервер и получает сообщения по очереди.Один клиентский процесс отправляет несколько сообщений на сервер.Теперь клиентский процесс подключается к серверу каждый раз, когда сообщение должно быть отправлено, а сообщения от разных клиентских процессов чередованно принимаются сервером.

Как распознать клиента?Я имею в виду, имеет ли процесс клиента значение идентификатора на сервере и является ли он одинаковым для процесса, даже если он подключается несколько раз.

Спасибо

Ответы [ 6 ]

3 голосов
/ 07 июня 2011

Если вы не согласны с идентификацией только по IP-адресу клиента, вам необходимо добавить какой-либо токен в сообщение. Вы можете (например) добавить в начало беседы сообщение, которое запрашивает уникальный токен, а затем требовать, чтобы один и тот же токен отправлялся в каждом сообщении от этого клиента.

2 голосов
/ 07 июня 2011

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

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

2 голосов
/ 07 июня 2011

Для связи через соединение вам необходимо accept(2) это соединение.Что принимает, сообщите нам?

int accept(int socket, struct sockaddr *restrict address,
       socklen_t *restrict address_len);

Адрес - это «идентификация» соединения.Таким образом, вы можете сделать это следующим образом:

  • Когда кто-то подключается, запишите его сокет (вот что возвращает accept(2)) и его адрес
  • Когда вы получите что-то через сокет (вы можете использовать select / epoll и т. д.) искать в вашем списке и находить совпадение между сокетом и адресом.

Теперь проблема в том, как это сделать: как сравнить адреса?Сравните каждое интересное поле для вашего протокола (для общего случая с протоколом TCP я бы сравнил IP и порт).

Как только соединение установлено, вы захотите «аутентифицировать» пользователя вкаким-то образом.Если аутентификация прошла успешно, вы можете добавить эту «информацию» к личности в вашем списке подключенных клиентов.

0 голосов
/ 07 июня 2011

Если вам нужен сервер для распознавания клиента, лучшим решением должно стать внедрение процесса аутентификации.Любое другое решение может основываться на фактическом установленном соединении (но это не сработает, если соединение закрыто) или на IP-адресе клиента (но это не сработает, если есть еще клиент с таким же адресом или если адрес изменился).

Клиент может аутентифицироваться на сервере, используя имя пользователя и пароль.Если клиент и сервер совместно используют ключ, каждое сообщение, которым они обмениваются, может быть аутентифицировано со знаком.Таким образом, сервер может идентифицировать отправителя, несмотря на IP-адрес полученного пакета.

0 голосов
/ 07 июня 2011

Я думаю, что ваша мысль верна.

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

Если клиент не может подключиться несколько раз, сервер может определить возвращаемое значение для каждого клиента 'accept (2)'; однако в вашем случае клиентам требуется несколько соединений, поэтому вам необходимо разработать собственный протокол для идентификации каждого клиента.

В моем случае, в предыдущем проекте я сделал UUID перед подключением к серверу и использовал UUID в качестве идентификатора клиента. В Mac OS X или Linux вы можете включить файл заголовка, который находится в /usr/include/uuid/uuid.h.

#include <uuid/uuid.h>

...
{
    uuid_t id;
    uuid_generate(id);
    ...
}

Затем вы можете получить случайное 128-битное значение в 'id'. Я использовал этот UUID в качестве идентификации клиентов. Может быть лучший способ определить каждого клиента.

0 голосов
/ 07 июня 2011

Нет способа, если у вас нет высокоуровневого протокола. Когда сокет закрыт, клиент исчез.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...