TServerSocket и несколько подключений

← →
Балбес (2007-08-07 22:09) [0]

Жили были SocketServer и два SpcketClientа в асинхронном режиме >_<. К ServerSocket.Socket.Connections[0] и Connections[1] подключено два пользователя: первый и второй. Если отключится второй и снова подключится то все будет хорошо, первый останется в Connections[0], второй соотв-но попадет в Connections[1]. Но если отключится первый (второй перемещается в Connections[0]?) и снова подключится, то по логике второй должен быть в Connections[0] а первый (последний подключившийся) в Connections[1]. НО! Connections[0] и Connections[1] указывают оба на последнего подключившегося, т.е. на первого. Такое может быть? Проблема в сокетах или в моей голове? :)

← →
Сергей М. © (2007-08-08 08:14) [1]

> если отключится первый (второй перемещается в Connections[0]?
> ) и снова подключится, то по логике второй должен быть в
> Connections[0] а первый (последний подключившийся) в Connections[1]

Да, именно так.

> НО! Connections[0] и Connections[1] указывают оба на последнего
> подключившегося, т.е. на первого. Такое может быть?

Нет, не может.

> Проблема в сокетах или в моей голове?

Где угодно, только не в сокетах.

← →
Сергей М. © (2007-08-08 08:57) [2]

И вообще - идентифицировать кл.соединения по их индексу в упомянутом списке не есть разумное решение.

Уникальность клиента вполне обеспечивается комбинацией RemoteAddress:RemotePort.

← →
Балбес (2007-08-08 11:34) [3]

> Уникальность клиента вполне обеспечивается комбинацией RemoteAddress:
> RemotePort.

Не всегда. Несколько клиентов могут быть подключены с одного IP (например, когда они из LAN с выходом в интернет) или даже с одного компьютера. Другое дело, давать ли одинаковым IP подключаться.

А дело все было в коде ^_^

← →
Сергей М. © (2007-08-08 11:38) [4]

> Не всегда

Всегда.

> например, когда они из LAN с выходом в интернет

Порты обязательно будут разные.

← →
Сергей М. © (2007-08-08 11:39) [5]

> или даже с одного компьютера

Тот же случай - порты будут разные.

← →
r.o.o.t © (2007-08-09 12:52) [6]

Удалено модератором
Примечание: Жаргон выключи плз...

← →
ViToTiV © (2007-09-13 10:48) [7]

Так как всётаки однозначно определить нужного клиента? Если допустим 1000 подключений к ServerSocket, как найти нужного? Получается нужно перебрать вссе коннекты поиском по IP? Типа:
for i:=1 to ServerSocket.ActiveConnection-1 do if ServerSocket.Conection[i].RemoteAddres=<IP> then <нашли нужного>
А проще никак?

← →
Сергей М. © (2007-09-13 11:56) [8]

> А проще никак?

Можно и проще.
Но для этого нужно все-таки определиться, по каким признакам должна осуществляться идентификация и откуда (и при каких условиях и в кааом виде) серверу будет поступать инф-ция для поиска и идентификации.

← →
ViToTiV © (2007-09-13 13:00) [9]

> нужно все-таки определиться, по каким признакам должна осуществляться
> идентификация

Так вот про это я и спрашивал, как будет сделать проще? По какому признаку? Запоминать при коннекте клиента его Handle, IP, Port, Host, SocketHandle или ёще что-нибудь? И как потом обратиться сразу к нужному сокету?

← →
Сергей М. © (2007-09-13 13:04) [10]

ты не ответил на вопрос - откуда (и при каких условиях и в кааом виде) серверу будет поступать инф-ция для поиска и идентификации .. Для выбора конкретного решения следует плясать именно от этого ..

← →
ViToTiV © (2007-09-13 15:23) [11]

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

← →
Сергей М. © (2007-09-13 15:29) [12]

Откуда, при каких условиях и в каком виде сервер получает информацию о необходимости послать сообщение такому-то клиенту ?

← →
Сергей М. © (2007-09-13 15:38) [13]

Т.е. кто есть, в твоем понимании, "такой-то" клиент ?

1. i-й клиент в списке Connections ?

2. Клиент с такой-то комбинацией адрес:порт ?

3. Клиент с таким-то хэндлом сокета ?

4. Клиент с таким-то адресом объекта TCustomWinSocket ?

5. Клиент с таким-то уникальным "ником", ассоциированным тем или иным способом с конкретным уникальным коннектом в списке Connections ?

6. Еще черт-те что и сбоку бантик ?

← →
ViToTiV © (2007-09-13 15:38) [14]

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

← →
Сергей М. © (2007-09-13 15:40) [15]

> ViToTiV © (13.09.07 15:38) [14]

см. [13]

← →
ViToTiV © (2007-09-13 15:50) [16]

> 5. Клиент с таким-то уникальным "ником", ассоциированным
> тем или иным способом с конкретным уникальным коннектом
> в списке Connections ?

Именно вот это! Вот меня и интересует вот этот "тот или иной способ" :)
Как проще всего знать сокет, для которого я хочу послать сообщение? Ведь если я просто запомню номер коннекта, то при отключении первых коннектов, все остальные коннекты смещаются, а мне нужно быть уверенным, что сервер посылает сообщение именно тому клиенту, которому нужно. Вот поэтому я и начал разговор про то, что серверу придётся всё время пробегать по всем коннектам, и смареть, тот это клиент (по IP, handly или ещё как) или нет?

> ViToTiV © (13.09.07 15:50) [16]

1. При коннекте создаешь некую структурированную запись, ассоциирующую ник с адресом соотв.объекта TCustomWinSocket. После проверки на уникальность ника добавляешь эту запись в свой собственный список, после чего сортируешь этот список в порядке возрастания или убывания ников, фигурирующих в записях списка, по требуемому тебе алфавитному порядку.

2. При дисконнекте ищешь в этом списке запись со ссылкой на соотв.объект TCustomWinSocket и удаляешь ее из списка.

3. При необходимости что-то послать клиенту с таким-то ником ищешь соотв.запись в своем списке и берешь из нее соотв.объект TCustomWinSocket.

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

> При необходимости что-то послать клиенту с таким-то ником
> ищешь соотв.запись в своем списке

Т.е. мне всё равно придётся искать по списку? Тогда какая разница, пройдусь ли я по всем ActiveConnection сервера и проверю RemoteAddres, или же я пройдусь по своему списку и натам его ник?

Ну это в принципе понятно, просто я думал что можно по проще как-то, как например по UDP, указал ip и вперёд...

> Т.е. мне всё равно придётся искать по списку?

Конечно)
Но поиск в сортированном списке в твоем случае гораздо эффективней, нежели в несортированном.

> Тогда какая разница, пройдусь ли я по всем ActiveConnection
> сервера и проверю RemoteAddres

Какой нафих RemoteAddres, если ты поставил условие поиск коннекта по нику ?)

> как например по UDP, указал ip и вперёд

А причем тут UDP ?

Он, этот ip, с луны что ли свалится ?)

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

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

> Какой нафих RemoteAddres, если ты поставил условие поиск
> коннекта по нику ?)

Ну так а что мне мешает хранить в и ник и айпи и имя компа и т.д.?
Вообщем, спасибо, как я думал, так всё и оказалось :)

> что мне мешает хранить в и ник и айпи и имя компа

А начерта дублировать информацию ?

Сетевые координаты коннекта хранит сам объект TCustomWinSocket, тебя они не волнуют в принципе, ибо все что от тебя требуется - имея конкретный ник быстро найти этот объект и вызвать его send-метод.

:))))))))))

TServerSocket и несколько подключений Найти похожие ветки