Algun cliente alguna vez debe haber sufrido de un extraño issue con los forms y se preguntara si vale la pena cambiarlos a ‘socket’ mode, y él se estará preguntando (con toda razón):
A. When the forms are changed to socket mode:
1. Will this affect the EBS application in anyway (will it be slow than now)
2. Do we need to perform any change on our or the workstation’s side ?
ASSESSMENT AND SOLUTION
Please look at the Note in Metalink 310976.1. It seems that the Java Console in JInitiator tells you at the beginning which mode you are using.
Verifying the Forms Client Connection to the Forms Server
Once the Applet has initialized and started, it connects to the Forms Listener, using the serverPort, serverHost and connectMode parameters displayed in the Java console. Steps to verify this are:
Check the serverPort port number and specified serverHost are correct
Verify the connectMode. In Applications 11i, the Forms Server must be started with the same connectMode (Socket, HTTP or HTTPS).
Socked mode is the standard…and:
- When the forms are changed to socket mode:
https://blogs.oracle.com/stevenChan/entry/which_is_better_forms_servlet_or_socket_mode
- Will this affect the EBS application in anyway (will it be slow than now)
No way.
2. Do we need to perform any change on our or the workstation’s side ?
Nope. Only the Midtier servers where forms is running
Just change a file like this:
/pfoxxi/applmgr/common/html/bin/appsweb_PFOXXI_auohsfoxx03.cfg
, and then bounce and that’s all.
MI EXPLICACION
Para mi la principal diferencia radica en como se establece el trafico a nivel ISO OSI si comparamos TCP Socket con Web Sockets.
Websockets difiere principalmente de TCP Sockets porque Websockets habilita una suerte de corriente de mensajería en vez de habilitar tan solo una corriente de bytes, me explico :
Cuando envias bytes desde un buffer por un socket TCP normal, la función de envío devuelve el número de bytes que se enviaron del búfer. Si se trata de non-blocking socket or de un envio no bloqueable , entonces el número de bytes que se envían puede ser menor que el tamaño del bufer. Si se trata de un blocking socket o un envio blockeable, entonces, el número devuelto coincidira con el tamaño del bufer, pero la llamada puede bloquearse . Con WebSockets , los datos que se pasan al método de envío son siempre enviados como un «mensaje», osea, se envía todo o nada en absoluto. Además , las implementaciones de WebSocket del navegador no bloquean la llamada de envío.
Pero hay diferencias más importantes que se encuentran en el lado de la recepción. Cuando el receptor hace una recv ( o lectura ) en un socket TCP , no hay garantía de que el número de bytes retornado corresponda a una solo envio ( o a una sola escritura ) en el lado del remitente. Puede ser que sea el mismo envio, pueden ser menos bytes (o cero bytes) y que incluso podrían ser más bytes (en cuyo caso bytes de múltiples envios / escrituras se estarán recibiendo ) . Con WebSockets , la recepción de un mensaje es manejado por eventos (tu generalmente registras una rutina controladora de mensajes ) ??, y los datos manejados por el evento son siempre el mensaje completo que la otra parte ha enviado.
Tengan en cuenta que tu puedes hacer la comunicación basada en mensajes utilizando sockets TCP , pero se necesita una capa extra/encapsulamiento que agrege datos de calce de las partes/mensajes para los mensajes de esa manera los mensajes originales se pueden volver a montar en las piezas. De hecho , WebSockets está construido sobre Sockets TCP normales y utiliza cabeceras de trama que contienen el tamaño de cada trama y las cuales indican que frames son parte de un mensaje . La API de WebSocket re-ensambla los fragmentos TCP de datos en los frames/tramas que son ensamblados en los mensajes antes de invocar el controlador de eventos de mensaje , lo que se hace una vez por mensaje.
Esta seria la conversación Cliente-Servidor de TCP Sockets
http://www.eg.bucknell.edu/~cs315/Spring12/wordpress/wp-content/uploads/2012/02/tcplab.png
