Clase TSocket. Una posible mejora.

[thefull]

Esta clase, a mi modo de ver, se puede mejorar en el lado cliente.

Supongamos el caso en que establecemos una conexion del lado del cliente,

Code: Select all  Expand view

      oSockClient := TSocket():New( 2000 )
      oSocketClient:bConnect = { || MyConnect() }
      oSocketClient:bRead    = { | oSocket | OnRead( oSocket ) }
      oSocketClient:bClose   = { || MsgInfo( "disconnected!" ) }
      oSocketClient:Connect( "localhost" )

STATIC FUNCTION MyConnect()
oMemo:Append( "CONECTADO" )
RETURN NIL


Bueno, si eso es ejecutado, al cabo del rato, salta el evento ONCONNECT, pero , si no tenemos escuchando ningun servidor en la ip correspondiente.

¿ Y que nos dice esto ? Que estamos conectado, lo cual no es cierto, pues SI NO EXISTE SERVIDOR, no podemos conectar, pero aún y asi, nos indica que estamos conectados, entonces, ¿ que esta mal ?

Bueno, realmente, según el api de windows, con los sockets asincrónicos, que son los que nos brinda Fivewin, el funcionamiento es correcto, es decir, el control pasa por el evento ONCONNECT en la clase TSocket, o a través del codeblock a nuestro disposición, bConnect.
El problema radica es que se produzca esto NO SIGNIFICA QUE ESTEMOS CONECTADOS!, para ello, necesitamos consultar el numero de error, que nos brinda ;

Code: Select all  Expand view

METHOD HandleEvent( nSocket, nOperation, nErrorCode ) CLASS TSocket


Ese nErrorCode TIENE que ser enviado al codeblock de evaluación, para poder de esta manera, el disponer de que es lo que ha pasado exactamente, porque la funcion WsaGetLastError(), no garantiza en este caso, que sea el error correcto que te informe.

Asi, se debería de modificar la clase TSocket en estos puntos:

Se recibe el nErrorCode y se envia al codeblock

Code: Select all  Expand view

METHOD  OnConnect( nErrorCode ) INLINE If( ::bConnect != nil, Eval( ::bConnect, Self, nErrorCode ),)


2.- En el method HandleEvent(), observamos como pasamos nErrocode.

Code: Select all  Expand view

         case nOperation == FD_CONNECT
              if ::lDebug .and. ! Empty( ::cLogFile )
                 LogFile( ::cLogFile, { "Connect",;
                          "Socket handle:" + Str( nSocket ) } )
              endif
              oSocket:OnConnect( nErrorCode ) // Aqui.....


Con esto retoques a la clase, ya podemos determinar en nuestro código que es lo que puede estar fallando en la conexion, quedando asi;

Code: Select all  Expand view

      oSocketClient:bConnect = { |o,nErrorCode| MyConnect( nErrorCode ) }

STATIC FUNCTION MyConnect( nErrorCode )
   if nErrorCode == 0
      oMemo:Append( Time()+ "-->Cliente iniciado en [ " +cIp + ":"+str( nPort, 5 ) + " ]" + CRLF )
   else
      oMemo:Append( "Error conexion..." + Str( nErrorCode ) +CRLF )
   endif

RETURN NIL


Ahora SI QUE PODEMOS DETERMINAR si estamos o no correctamente conectado.

Antonio, ¿ crees que es posible meter esta mejora ? También se podria hacer lo mismo para los otros eventos, he explicado este pues es con el que he tenido que pelearme esta tarde.

Ademas, me he percatado de una cosa muy curiosa, ::nTimeOut,
¿ donde se hace uso de esto , y realmente se usa ?
Miraré mañana más sobre esto.

[Vikthor]

Rafa :

Y mientras el cliente espera la respuesta del server cómo avisas al usuario lo que esta pasando ?

En dado caso de que un cliente se trate de conectar a la nada, la respuesta no es inmediata.

Y la aplicación no se queda "congelada" sino que sigue operando.

[Antonio Linares]

Vikthor,

Tienes que establecer un "timeout" (tiempo limite de espera) para que la aplicación no espere eternamente. Te refieres a eso ?

[Vikthor]

no , a lo que me refiero es lo que puedo hacer miestras espero la respuesta, por que en el tiempo que se recibe la respuesta el sistema no se queda en pausa, y lo que yo pretendo es mostrar un mensaje tipo msgrun() cuando se esta esperando la respuesta.

Vikthor,

Tienes que establecer un "timeout" (tiempo limite de espera) para que la aplicación no espere eternamente. Te refieres a eso ?

[Antonio Linares]

Vikthor,

Si la conexión es asíncrona entonces podrías usar un MsgRun() sin problemas hasta que necibas el evento de notificación de conexión.

[thefull]

Victor , como dice Antonio, como lo que estamos usando son sockets asincronicos, y como bien dices, la aplicación no se para...
Pues entonces puedes hacer lo que quieras, , mostrar un dialogo no wait por ejemplo, y cuando salte el evento del OnConnect(), pues matar ese dialogo, etc... , la imaginación al poder