Sincronizar ServerSocket y ListView
 

Estoy programando una aplicación cliente servidor.
La cuestión está en el Server, en este he colocado un listview que muestra las conexiones + datos que envian los clientes.

Haciendo click sobre el listView puedo mandar comandos a los clientes, por eso es importante que el index de los items en el listView esté sincronizado con las conexiones en el Socket.

El problema es que la sincronización no es total ya que a veces un cliente se va sin cerrar la conexión, luego se conecta otro, luego se refrescan las conexiones activas (con un timer que puse) y ya la listView y el socket va cada uno por su lado :(
Otro problema es que cuando se desconectan los elimino de la listView buscando la IP en el Caption del Item pero podría tener dos conexiones dede la misma IP y solo desconectarse una (ej. si hay dos clientes detrás de un router o en LAN).

Acá les pongo parte del código a ver si me pueden tirar alguna ideita.
Saludos :)

-----------------------------------

procedure TForm1.ServerSocket1ClientConnect(Sender: TObject;
Socket: TCustomWinSocket);
var
lvItem: TListItem;
begin
ListView1.Items.Add.Caption:=Socket.RemoteAddress;
end;

procedure TForm1.ServerSocket1ClientRead(Sender: TObject;
Socket: TCustomWinSocket);
var
s: string;
lvItem: TListItem;
begin
s:= Socket.ReceiveText;
if copy(s,1,7)='details' then begin
lvItem:= ListView1.FindCaption(0,Socket.RemoteAddress,true,true,false);
if lvItem <> nil then begin
lvItem.SubItems.Add(GetToken(S,';',2));
lvItem.SubItems.Add(GetToken(S,';',3));
lvItem.SubItems.Add(GetToken(S,';',4));
lvItem.SubItems.Add(GetToken(S,';',5));
end;
end;
end;

procedure TForm1.ServerSocket1ClientDisconnect(Sender: TObject;
Socket: TCustomWinSocket);
var
lvItem: TListItem;
begin
lvItem:=ListView1.FindCaption(0,Socket.RemoteAddress,true,true,false);
if lvItem <> nil then
lvItem.Delete;
end;

// con el timer les mando texto a los clientes para que el socket
// desconecte a los que se han ido sin avisar.

procedure TForm1.Timer1Timer(Sender: TObject);
begin
i2check:=(i2check+1); {item a checkear}

if ListView1.Items.Count-1<i2check then begin
i2check:=-1;
exit;
end
else
ServerSocket1.Socket.Connections[i2check].SendText('lala');
end;
end;

No conozco mucho de sockets pero en términos generales pienso que tu problema no es de sockets. Me explico:

Tú mismo te has dado cuenta de la dificultad de sincronizar el índice de un ítem en el listview y una conexión.

Lo que yo haría es utilizar la propiedad Data de TListItem. Data es un puntero de manera que puedes almacenar ahí virtualmente cualquier cosa. Podrías asignar una estructura- por ejemplo un record -a cada conexión nueva en la que incluyas los datos que identifiquen de manera única a la conexión:

Al momento de entrar una nueva conexión asignas una de estas estructuras a Data:

Cuando necesites tomar datos de la estructura de, por ejemplo, el ítem seleccionado haces un moldeo de datos:

y usas el evento OnDeletion (creo que se llama así) del listview para liberar memoria del puntero.

De esta forma cada ítem del listview "apuntará" a la estructura correcta sin depender de su posición en la lista. Además puedes guardar en dicha estructura otros datos de la conexión que necesites y no desees colocar en el listview.

// Saludos

Ante todo, gracias roman por tu ayuda.

Eso que explicas es nuevo para mi, no se si lo entendí bien (tendré que seguir estudiandolo) pero creo que volvería a enfrentar el mismo problema.

Cuando un cliente se desconecta solo se su IP (la cual veo en el evento OnDisconnect) pero no se el número de conexión que tenía en el ServerSocket, por eso no puedo reflejarlo en la listView (si hay 2 IP iguales).
Si hay alguna forma de saber esto tendría el 80% del problema solucionado.

Bueno... seguiré pensando y abierto a sugerencias

Hola.

Has considerado el uso de las indy. El servidor TCP presenta varias ventajas con respdecto del ServerSocket. Básicamente, es un servidor multihilos que atiende "mejor" a los clientes... además, en tu caso particular, el evento OnDisconnect tiene un puntero al thread del cliente, donde tenes toda la información "puntual" de su conexión... de esa forma, una misma ip puede estar conectada 20 veces, sin provocar confusión en el servidor...

Hasta luego.

;)

Olvide mencionar, también para tu caso en partícular, que en el método Timer1Timer podrias recorrer la propiedad Threads del servidor para actualizar tu ListView (si esto fuera necesario, claro... ya que creo que con el evento OnDisconnect bastaria para mantenerla en sincronía)

Hasta luego.

;)

Parece que finalmente tendré que aprender a usar las Indy :rolleyes:

Gracias por el dato, ya os contaré :)

Estoy intentandolo con el idTCPserver, veo que es muy completo y más complejo. He leido la ayuda de Indy y estudiado los ejemplos, sin embargo todavía no entiendo mucho de la jerga de la programación por lo que se me hace difícil comprender las ayudas.
Después de decenas de intentos no me queda otra que preguntarles.

¿cómo hago para saber el hilo que se crea al conectar para agregarlo al caption del item en el listview?
(si es que eso me permitiría identificar las conexiones).

procedure TForm1.IdTCPServer1Connect(AThread: TIdPeerThread);
var
ali: TListItem;
begin
aLi := ListView1.Items.Add;
with aLi do
begin
Caption:= IdTCPServer1. {no se que poner acá}
end;
end;

Saludos

Que queres poner en el caption??

Fijate en el parámetro AThread que recibis... es el "hilo" en que se ejecutará tu conexión, tiene una propiedad llamada Connection...

Podrias hacer algo como:

Caption := AThread.Connection.LocalName;

Es recomendable, de cualquier forma, que para poder identificar una conexión cualquiera, y dado que pueden conectarse varias veces de un mismo equipo, guardes un apuntador al Thread... del que habrá uno solo para cada conexión.

Hasta luego.

;)

Lo probé y me pone el nombre de mi pc, aunque lo de AThread ya es un comiezo :D

¿Se puede poner en el caption directamente el Thread que identifica a cada conexió? (Para no tener que meterme con los apuntadores). ¿Si es así como se pone?.

Gracias por ayudarme :p

El caption es una propiedad de tipo string. El thread es un objeto de tipo TidPeerThread.

En conclusión: El thread no puede ponerse como caption, por razones obvias. Asi, que a meterse con los apuntadores... que no es tan complicado al fin de cuentas. Ya cada elemento del ListView (de tipo TListItem) incorpora una propiedad data que es un apuntador genérico. Solo hace que apunte al thread, y listo.

Hasta luego.

;)

Seguiré tu consejo, tengo unos pdf sobre el tema.

Gracias !!!

Luego de tomar distancia del proyecto volver logré hacerlo funcionar y sin usar los INDY.
Lo he probado a fondo y anda muy bien, aunque con las INDY tal vez hubiera quedado más prolijo.
Acá les dejo la solución por si a alguien le sirve.

Usando Socket.RemoteAddress te devuelve un entero que es el sock y que es único por cada conexión.


Saludos :)

Imagínate que quieres mantener varias conexiones por IP y además quieres mandar un mensaje a una determinada conexión, tan rápidamente como acceder a una lista de referencias a las conexiones. Ese era mi problema con un juego en línea que hice. Lo solucioné lo más directamente posible, agregue en el código fuente "sockets.pas", en el constructor de ese objeto un entero que me serviría como identificador (lo inicializo en "NoIdentificado"=-1). De esa forma al momento de iniciar la conexión le asigno un número identificador y además tengo mi lista de referencias a conexiones, en la posición del indentificador asigno la referencia a la conexion. Con ambas cosas tengo acceso total a cada conexión sin importar el IP. siempre se con cual conexion estoy trabajando y siempre puedo mandar un mensaje a la conexion que quiera. Eso me ayudo mucho también a relacionar la información de cada jugador con su conexión y viceversa.

Una cosa más: (Pero creo que ya te diste cuenta)

Si usas el "sockets.pas" cuando envías:

"Hola" y luego "Mundo" pueden recibir: "Hola" y luego "Mundo", "HolaMundo" y también "Ho", "laM","un" y finalmente "do". El 1er caso es típico cuando envías los mensajes con cierto tiempo ellos. El 2do caso cuando los envías uno detrás de otro casi inmediatamente y el 3er caso cuando el canal de transmisión está saturado pero generalmente esa fragmentación al recibir el mensaje ocurrirá con mensajes más largos.

Supongo que esto será problema de "delimitación" de los mensajes, pues con las Indy nunca he visto nada similar. Como siempre, TCP/IP garantiza que, a nivel de aplicación, los mensajes lleguen integros y en orden.

Hasta luego.

;)

hola gente soy novato en todo esto de programacion pero por algo se empiesa yo estaba asiendo algo como esto y no se donde poner esto en q clase de boton o en el listview no encuentro como alguien me lo esplica si esta n amable...

saludos!!! y muchas grasias