Enfora GSM128 Socket UDP vs. Socket TCP/IP
otttooo
Si se pretende crear un un socket con protocolo de resolución de trafico, entonces lo mas inidcado es un envio de información en Streamer, y generar el protocolo en ambos extremos de la comunicación , que a la postre terminara pareciendose a el TCP/IP.
Para el caso concreto del ENFORA GSM128, con interación con sitio Web, el uso de socket independiente no es lo indicado , ya que las paginas web tienen sus propios socket (80 y 8080) con protoclos UDF y TCP/IP, colocar un socket como demonio . para que capture la información , aun que sin duda es posible , pienso no es lo mas indicado , pues en este caso creamos un cuello de botella en la apliación , al obligar el sitio web a estar pendiente de los eventos, desde un spooler generado eventuamente con el nuevo demonio que opera el socket.
Creo que una solución mas práctica es dejar que sea el sitio quien atienda y opere la informacion que llega desde el dispositivo conectado al ENFORA GSM128, recordemos que el ENFORA es solo el canal de comunicación y por lo anto no podemos pretender que resuelva los inconvenientes de operación de la aplicación, para la manipulación del sitio desde el dispositivo remoto contamos con los comandos de Http GET y POST , que permiten operar la página y darle ordenes directas sin pasar por ningún socket intermediario los puertos 80/8080 por ejemplo.
Ya que cada llamada a GET/POST genera su propio hilo y no es necesario estar pendientes del correcto funcionamiento de ellos. del lado del "escuchador" debemos crear un "formulario" que acepte los comandos del "hablador" para ejecturar las ordenes pertinentes. (ver comando http INPUT para generación de formularios)
En caso de tener demaciadas peticiones desde dispositivos remotos , un blanceador de cargas es sufiente , sin la necesidad de cambiar la aplicación y sin peder el control.
Método GET: se envía una petición típica con el verbo GET. Los datos a enviar se incluyen dentro de la propia URL de la petición, precedidos del carácter "?", y se componen de un conjunto de pares "variable"-"valor". Estas "variables" y "valores" deben codificarse de un modo especial, llamado "application/x-form-urlencoded"
Un ejemplo seria sencillo: enviar un valor de temperatura , por ejemplo 39 grados del paciente Carlos al servidor www.misitio.com para que en el el procedimiento de ingreso de formulario llamado lea_temperatura.html lo procese y determine si lo presenta o lo almacena en una base de datos
Esta seria la cadena a pasar al ENFORAGSM128 :
http://www.misitio.com/lea_temperatura.html?temperatura=39&paciente=carlos
Método POST: los datos se envían dentro del cuerpo de la petición, y no como parte de la URL. Como ya sabemos, cada petición HTTP se formaba de un grupo de cabeceras (Accept, Content-type, Content-Length, etc.) y un retorno de carro. Las peticiones de tipo POST tienen un elemento adicional después del retorno de carro: los datos a enviar. Sabiendo esto, una petición POST tiene el siguiente aspecto para la misma cadena anterior:
Ante una señal enviada por el cliente al servidor, este responde
Entonces podemos verificar en dispositivo si el envio fue correcto explorando la cadena y buscando la palabra OK
en la cadena despachada por el servidor
LA CADENA LUCE ASI:
HTTP/1.1 200 OK
Date: Mon, 11 MARC 2011 7:25:10 GMT
Server: Tomcat/2.0.40 (Mandriva 201)
Last-Modified: Tue, 11 Mar 2011 07:53:53 GMT
Accept-Ranges: bytes
Content-Length: 10
Connection: close
Es importante notar , y sobre eso debo hacer mucho enfasis que los modem GPRS, nos proporionan un "tunel" de comunicación , hecho con el protocolo TCP/UDP , cuando tiene implementada esta prestación, pero aqui la palabra tunel es usado en su mas puro sentido, de algo que permite el paso, mas no efectua en si mismo ninguna operación, esta aclaración obedece a que en muchos de los manuales de los modem GPRS que he utilizado , se habla de manera indiscriminada de TCP/UDP, como un protocolo, un tunel, un servicio y un socket, lo cual desde luego genera mucha confusión.
Quedamos entonces que el el modem genera es un "tunel" de comunicación efectuado con el protocolo TCP/UDP , ojo que no dije y soy claro TCP/IP no TCP/UDP no es lo mismo., ya que en TCP/UDP es solo el tunel y a cada lado del mismo
debe haber algo que efectua el proceso que necesitamos realizar , que en el caso particular de los modem GPRS, sea un socket (cliente/servidor)
, creado y definido por nosotros ya sea hecho en java, c,c++ ,php o cualquier otro lenguaje que lo permita, o podemos usar un socket pre-definido como puede ser Http, shh, ftp etc , todos desde luego pueden ser declarados como servicios
de arranque automatico al momento del incio del sistema o por el contrario como un servicio de arranque manual, desde luego esto dependera de la necesidad de cada quien, además se debe tener claro que el programa que va aactuar como servidor de socket tiene que tener asignado un número de puerto, que en los servicios "bien conocidos" , que es como se denominan los puertos, del 1-1023 del tipo 22 para ssh, 80 para http , 21 telnet etc, quedan los demas para ser definidos or el usuario.
Toda esta aclaracíon suele tenernos sin cuidado , si estamos usando el modem GPRS, para comunicar dos computadores , pues bastante comuún que una vez establecido el tunel TCP/UDP, por la comunicción del modem GPRS, el uso del programa a ambos extremos de la comunción, sea transparente para nosotros, pues existiran con toda seguridad un servidor http y un navegador al otro extremo con lo cual la dificultad y el concepto de socket, tunel y servicio queda traslapado, pero otra cosa muy distntinta es cuando en el aplicativo que estamos haciendo el "cliente· es un micro-controlador, ya que en este , el procotolo TCP/UDP que el modem brinda sigue , exisitendo, eventualemnte, el socket en el servidor con su número de puerto también , pero el problema es que a menos que tengamos un muy poderoso microcontrolador, lo mas probable es que no tengamos un socket-cliente para el servidor que vamos a usar.
En otras palabras, en general , no basta simplemente mandar a travs del modem un "hola mundo", para que todo funcione, pues el servidor , no solo espera la informaciíon de acuerdo al protocolo TCP/UDP, sino que además debe cumplirse con todos los requerimientos usados en el protocolo implementado en el socket, por ejemplo para comunicarnos por un servidor htpp (como vimos anteriormente), debemos usar los comandos y cabecra propios de http , llamado GET , y si es ssh, debemos coniocer los comandos y cabeceras que hay que enviar para invocar el ssh y poder usarlo correctamente.
En estos casos casi que es obligatorio crearnios nuestros propios socket cliente-servidor con los protocolos y cabeceras que concideremos adecuados
Ampliación del tópico en:
http://cac9999.blogspot.com/2012/08/modem-gprs-y-protocolo-tcpudp.html
Carlos Arturo Castaño G.
Enfora GSM128 Socket UDP vs. Socket TCP/IP
Debemos entender la filosofía y el protocolo tanto de UDP y TCP/IP para a la creación del Socket para no crear falsas expectativas con respecto a lo que de estos se espera.
En una trasmisión de tipo UDP, no se espera en último término que todos los mensajes que se envíen lleguen a su correspondiente destino y por ende menos se espera que haya una respuesta de un “interlocutor”, de la forma como está hecho este tipo de protocolo , no puede esperarse que exista un socket que atienda todos los mensajes y no deje perder ninguno, ya que si un brodcast está emitiendo mensajes y otro también el socket simplemente eliminara a uno de los dos, si creamos dos hilos para conjurar este tipo de inconveniente, siempre habrá la posibilidad de que un tercero efectué un llamado que no se pueda atender , tendríamos entones la necesidad de un tercer hilo y así sucesivamente.
Todo lo anterior sin tener en cuenta que no estamos respondiendo nada, solo “escuchando”, si a esto le sumamos que además tenemos que responder algunos de estos mensajes, tres hilos no van a ser sufrientes tendríamos que tener 6 hilos y así sucesivamente, lo más parecido a este escenario, es el de una fiesta en el que todo mundo habla, un potencial invitado solo alcanzara a discernir sobre una o dos conversaciones si mucho, el resto de la información es ruido, que hay que dejar pasar.
Por eso no se puede convertir el socket UDP, en un “resolvedor” de protocolo de atención uno a uno.
TCP /IP tiene un contexto totalmente diferente, en este quien habla envía un mensaje , indicando que lo va hacer y espera la respuesta del potencial interlocutor, si este no está “escuchando”, el que inicia la conversación, espera un momento antes de intentarlo de nuevo ,así hasta un número de veces finito , hasta que alanza el valor programado de “time out”, si ante una señal del llamador el “escuchador”, dice estar atendiendo , la conversación se inicia , con el consiguiente envío de información de una a otro parte y viceversa, mientras esto sucede , ningún otro potencial “hablador” , lo hace hasta que el "escuchador" le indique que puede hacerlo , si ocurriera que el escuchador no recibe la trama completa, solícita al “hablador” que se la envíe de nuevo, la forma más similar es este escenario es el de un auditorio , donde el "escuchador" solo le da la palabra a un “hablador” ,entre tanto todos los demás callan, y solo pueden pedir la palabra cuando el escuchador , lo indique.
En este escenario el socket solo recibe y trasmite un mensaje a la vez, no necesita hilos , ni nada, ya que es el protocolo quien resuelve el problema , a quien y cuando el socket debe escuchar y contestar. y verificar que la señal de uno a otro extremo llegue completa.
Si se pretende crear un un socket con protocolo de resolución de trafico, entonces lo mas inidcado es un envio de información en Streamer, y generar el protocolo en ambos extremos de la comunicación , que a la postre terminara pareciendose a el TCP/IP.
Para el caso concreto del ENFORA GSM128, con interación con sitio Web, el uso de socket independiente no es lo indicado , ya que las paginas web tienen sus propios socket (80 y 8080) con protoclos UDF y TCP/IP, colocar un socket como demonio . para que capture la información , aun que sin duda es posible , pienso no es lo mas indicado , pues en este caso creamos un cuello de botella en la apliación , al obligar el sitio web a estar pendiente de los eventos, desde un spooler generado eventuamente con el nuevo demonio que opera el socket.
Creo que una solución mas práctica es dejar que sea el sitio quien atienda y opere la informacion que llega desde el dispositivo conectado al ENFORA GSM128, recordemos que el ENFORA es solo el canal de comunicación y por lo anto no podemos pretender que resuelva los inconvenientes de operación de la aplicación, para la manipulación del sitio desde el dispositivo remoto contamos con los comandos de Http GET y POST , que permiten operar la página y darle ordenes directas sin pasar por ningún socket intermediario los puertos 80/8080 por ejemplo.
Ya que cada llamada a GET/POST genera su propio hilo y no es necesario estar pendientes del correcto funcionamiento de ellos. del lado del "escuchador" debemos crear un "formulario" que acepte los comandos del "hablador" para ejecturar las ordenes pertinentes. (ver comando http INPUT para generación de formularios)
En caso de tener demaciadas peticiones desde dispositivos remotos , un blanceador de cargas es sufiente , sin la necesidad de cambiar la aplicación y sin peder el control.
Método GET: se envía una petición típica con el verbo GET. Los datos a enviar se incluyen dentro de la propia URL de la petición, precedidos del carácter "?", y se componen de un conjunto de pares "variable"-"valor". Estas "variables" y "valores" deben codificarse de un modo especial, llamado "application/x-form-urlencoded"
Un ejemplo seria sencillo: enviar un valor de temperatura , por ejemplo 39 grados del paciente Carlos al servidor www.misitio.com para que en el el procedimiento de ingreso de formulario llamado lea_temperatura.html lo procese y determine si lo presenta o lo almacena en una base de datos
Esta seria la cadena a pasar al ENFORAGSM128 :
http://www.misitio.com/lea_temperatura.html?temperatura=39&paciente=carlos
Método POST: los datos se envían dentro del cuerpo de la petición, y no como parte de la URL. Como ya sabemos, cada petición HTTP se formaba de un grupo de cabeceras (Accept, Content-type, Content-Length, etc.) y un retorno de carro. Las peticiones de tipo POST tienen un elemento adicional después del retorno de carro: los datos a enviar. Sabiendo esto, una petición POST tiene el siguiente aspecto para la misma cadena anterior:
POST /lea_temperatura.html
HTTP/1.0Host:www.misitio.com
http://www.misitio.com /lea_temperatura?tempertura=39&cliente=carlos
User-Agent: Mozilla/4.5 [en]
Accept-language: en Accept-Charset: iso-8859-1Ante una señal enviada por el cliente al servidor, este responde
Entonces podemos verificar en dispositivo si el envio fue correcto explorando la cadena y buscando la palabra OK
en la cadena despachada por el servidor
LA CADENA LUCE ASI:
HTTP/1.1 200 OK
Date: Mon, 11 MARC 2011 7:25:10 GMT
Server: Tomcat/2.0.40 (Mandriva 201)
Last-Modified: Tue, 11 Mar 2011 07:53:53 GMT
Accept-Ranges: bytes
Content-Length: 10
Connection: close
Es importante notar , y sobre eso debo hacer mucho enfasis que los modem GPRS, nos proporionan un "tunel" de comunicación , hecho con el protocolo TCP/UDP , cuando tiene implementada esta prestación, pero aqui la palabra tunel es usado en su mas puro sentido, de algo que permite el paso, mas no efectua en si mismo ninguna operación, esta aclaración obedece a que en muchos de los manuales de los modem GPRS que he utilizado , se habla de manera indiscriminada de TCP/UDP, como un protocolo, un tunel, un servicio y un socket, lo cual desde luego genera mucha confusión.
Quedamos entonces que el el modem genera es un "tunel" de comunicación efectuado con el protocolo TCP/UDP , ojo que no dije y soy claro TCP/IP no TCP/UDP no es lo mismo., ya que en TCP/UDP es solo el tunel y a cada lado del mismo
debe haber algo que efectua el proceso que necesitamos realizar , que en el caso particular de los modem GPRS, sea un socket (cliente/servidor)
, creado y definido por nosotros ya sea hecho en java, c,c++ ,php o cualquier otro lenguaje que lo permita, o podemos usar un socket pre-definido como puede ser Http, shh, ftp etc , todos desde luego pueden ser declarados como servicios
de arranque automatico al momento del incio del sistema o por el contrario como un servicio de arranque manual, desde luego esto dependera de la necesidad de cada quien, además se debe tener claro que el programa que va aactuar como servidor de socket tiene que tener asignado un número de puerto, que en los servicios "bien conocidos" , que es como se denominan los puertos, del 1-1023 del tipo 22 para ssh, 80 para http , 21 telnet etc, quedan los demas para ser definidos or el usuario.
Toda esta aclaracíon suele tenernos sin cuidado , si estamos usando el modem GPRS, para comunicar dos computadores , pues bastante comuún que una vez establecido el tunel TCP/UDP, por la comunicción del modem GPRS, el uso del programa a ambos extremos de la comunción, sea transparente para nosotros, pues existiran con toda seguridad un servidor http y un navegador al otro extremo con lo cual la dificultad y el concepto de socket, tunel y servicio queda traslapado, pero otra cosa muy distntinta es cuando en el aplicativo que estamos haciendo el "cliente· es un micro-controlador, ya que en este , el procotolo TCP/UDP que el modem brinda sigue , exisitendo, eventualemnte, el socket en el servidor con su número de puerto también , pero el problema es que a menos que tengamos un muy poderoso microcontrolador, lo mas probable es que no tengamos un socket-cliente para el servidor que vamos a usar.
En otras palabras, en general , no basta simplemente mandar a travs del modem un "hola mundo", para que todo funcione, pues el servidor , no solo espera la informaciíon de acuerdo al protocolo TCP/UDP, sino que además debe cumplirse con todos los requerimientos usados en el protocolo implementado en el socket, por ejemplo para comunicarnos por un servidor htpp (como vimos anteriormente), debemos usar los comandos y cabecra propios de http , llamado GET , y si es ssh, debemos coniocer los comandos y cabeceras que hay que enviar para invocar el ssh y poder usarlo correctamente.
En estos casos casi que es obligatorio crearnios nuestros propios socket cliente-servidor con los protocolos y cabeceras que concideremos adecuados
Ampliación del tópico en:
http://cac9999.blogspot.com/2012/08/modem-gprs-y-protocolo-tcpudp.html
Carlos Arturo Castaño G.
Comentarios
Publicar un comentario