Buenas estoy con algo q me traba un poco en el desarrollo del TP,
me piden que por me registre siendo el cliente en el web server que ya lo
hice y le mande un mensaje al web server con un Post de HTTP,
mi duda es q no se como hacerlo en C no entiendo como tratarlo, si tengo
que usar string o una estructura o que hacer estoy re perdido con esto,
si alguien tiene un ejemplo de codigo mas o menos explicado me vendria joya
Gracias, espero respuestas.

Primero, tratalo como un string (osea, char *)

Una vez que tengas el string hecho, lo envias.

Supongamos que tenes un string llamado "mensajeAEnviar".

 send(<Socket que declaraste antes>, mensajeAEnviar, strlen(mensajeAEnviar), 0);

En realidad, lo que le envias es un STREAM, no un STRING. Ya que cuando el "cliente" lo recibe, lo recibe SIN el '\0' que tiene todo string.

(no se si lo sabias: En C, un String es un array de Chars, el cual tiene como ultimo caracter, el '\0'. Vos cuando se lo envias al cliente, le envias TODO el mensaje MENOS el '\0' del final. strlen(mensajeAEnviar) te retorna el "largo" que tiene la cadena, sin el '\0', asique no te tenes que preocupar por nada, vos manejalo como un String siempre, y siempre que lo envies, usa "strlen(mensajeAEnviar)" y listo).

sirvio?

P.D.: Acordate que los mensajes HTTP terminan con \r\n\r\n, ejemplo de un GET: " GET /index.html HTTP/1.1 \r\n\r\n"

Antes que nada, planteate lo siguiente.

Tenés que trabajar con dos métodos:

1. GET. La data que se quiere "enviar"/"pedir" viaja en la url que se escriba.
   Ej:
   GET /index.html?userid=joe&password=guessme HTTP/1.1
2. POST. La data viaja dentro del cuerpo del mensaje, y no a través de la url. Esto hace que se evite ver los datos en la url, además de que se puede enviar más información que a través de un GET.
   
   Ej:
   POST /foro/member.php HTTP/1.1
   
   Host: http://www.utnianos.com.ar
   User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; es-AR; rv:1.9.2.8) Gecko/20100723 Ubuntu/9.10 (karmic) Firefox/3.6.8
   Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
   Accept-Language: es-ar,es;q=0.8,en-us;q=0.5,en;q=0.3
   Accept-Encoding: gzip,deflate
   Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
   Keep-Alive: 115
   Connection: keep-alive
   Referer: http://www.utnianos.com.ar/foro/index.php
   Cookie: __utma=71202260.1731399378.1283831047.1284927696.1285074747.24; __utmz=71202260.1285074747.24.2.utmcsr=google|utmccn=(organic)|utmcmd=organic|utmctr=utenianos; __utmb=71202260.27.10.1285074747; __utmc=71202260; mybb_mybb[lastvisit]=1285082525; mybb_mybb[lastactive]=1285082525; mybb_sid=33357ace50675d166accc069ce623e1a
   
   Content-Type: application/x-www-form-urlencoded
   Content-Length: 171
   action=do_login&url=http%3A%2F%2Fwww.utnianos.com.ar%2Fforo%2Findex.php&quick_login=1&quick_username=Matias+Dumrauf&quick_password=***********&submit=Iniciar+Sesi%C3%B3n
   

Ahora, a nivel código: cómo lo interpretás?

Lógicamente, es una conexión por sockets. A tu servidor le van a tirar un connect cada vez que un browser se quiera conectar().

Una vez conectado (el servidor hizo un accept), cuando hagas un recv() te va a llegar toda la cabecera del mensaje. Entonces, vos tenés que parsear la cabecera (a mano, ya que no podés usar ninguna api externa) para obtener la información que a vos te interese, por ejemplo: en el caso del GET, parseo para obtener la versión del protocolo que usa el cliente y el pedido. Y a su vez, parseo el pedido para diferenciar la url que me escribieron, de la información que me llegó a través del form (es decir, despues del signo '?').

Las respuestas que le tenés que enviar al cliente HTTP tienen que ser tal y como especifica Teseracto: terminando en \r\n\r\r. Ahora, cada pedido tiene una respuesta, por ejemplo, si fue válida, se le responde con un HTTP 200 OK, con un correspondiente Content-Type. Y a continuación, el mensaje que quieras enviar. Pero siempre el mensaje de respuesta primero (puede ser un HTTP 404 NOT FOUND, un HTTP 505 INTERNAL SERVER ERROR, etc.).


Una cosa más: si querés ver los headers de las páginas, para tener ejemplos de como van viajando, podés bajar el plugin del Firefox Live HTTP Headers. Está muy bueno, me ayudó mucho.

(ah, lei cualquiera, pense que estaba haciendo el cliente ).

(21-09-2010 14:09)Teseracto escribió:  (ah, lei cualquiera, pense que estaba haciendo el cliente ).

Jajaj como Cliente usan cualquier browser (IE, Firefox, Chrome). La única vez que hubo que implementar un cliente que utilizara el protocolo HTTP fue en la cursada de 2do Cuatrimestre de 2008. Estuvo bastante bueno, era un Cliente de Descargas conectado a una Red tipo eMule, administrada por un Network Server, que tenia un proceso Cache Server donde almacenaba los pedidos más recientes, hasta tenía una red Gnutella con nodos que se podían caer/tirar abajo, y se tenían que re-descubrir. Cada nodo era un File Server. Similar al TP de este Cuatrimestre donde se tiene un Grid de Nodos, y uno de ellos es un DC (Distribuidor de Carga).

Gracias gente ya lo empeze a encaminar era lo q me faltaba para arrancar,
hasta la proxima pregunta abrazo!!!

(21-09-2010 16:04)Matias Dumrauf escribió:  

(21-09-2010 14:09)Teseracto escribió:  (ah, lei cualquiera, pense que estaba haciendo el cliente ).

Jajaj como Cliente usan cualquier browser (IE, Firefox, Chrome). La única vez que hubo que implementar un cliente que utilizara el protocolo HTTP fue en la cursada de 2do Cuatrimestre de 2008. Estuvo bastante bueno, era un Cliente de Descargas conectado a una Red tipo eMule, administrada por un Network Server, que tenia un proceso Cache Server donde almacenaba los pedidos más recientes, hasta tenía una red Gnutella con nodos que se podían caer/tirar abajo, y se tenían que re-descubrir. Cada nodo era un File Server. Similar al TP de este Cuatrimestre donde se tiene un Grid de Nodos, y uno de ellos es un DC (Distribuidor de Carga).

Se me pianta un lagrimon jaja.

Cita:Similar al TP de este Cuatrimestre donde se tiene un Grid de Nodos, y uno de ellos es un DC (Distribuidor de Carga).

A mi tambien se me pianta un lagrimon, es el tp que hice :')

Creo que justo lo que mencionas, es lo que tiene de distinto. En el tp - 2do cuatrimestre 2008, no tenias un grid de nodos, ni tampoco un distribuidor de carga. Los nodos formaban una estructura de arbol, y no habia carga para distribuir: el servidor que recibia mensajes del cliente, se encargaba de enviar mensajes que al final eran recibidos por todos los nodos del arbol.

En lo que si lo veo similar, es en el algoritmo de islas, y que tenes nodos .

Como venia de ese tp, pense que talvez en este tambien tenias que hacer un cliente http .

(21-09-2010 23:49)Teseracto escribió:  

Cita:Similar al TP de este Cuatrimestre donde se tiene un Grid de Nodos, y uno de ellos es un DC (Distribuidor de Carga).

A mi tambien se me pianta un lagrimon, es el tp que hice :')

Creo que justo lo que mencionas, es lo que tiene de distinto. En el tp - 2do cuatrimestre 2008, no tenias un grid de nodos, ni tampoco un distribuidor de carga. Los nodos formaban una estructura de arbol, y no habia carga para distribuir: el servidor que recibia mensajes del cliente, se encargaba de enviar mensajes que al final eran recibidos por todos los nodos del arbol.

En lo que si lo veo similar, es en el algoritmo de islas, y que tenes nodos .

Como venia de ese tp, pense que talvez en este tambien tenias que hacer un cliente http .

Jajaj que groso recordar tps anteriores de esta manera. =) Podría estar horas hablando de todos los TPs que hice. Aprendí bocha.

Con respecto a lo de este TP comparado con el del 2do Cuatrimestre de 2008, es exactamente como vos decís. De echo, no existía distribución de carga ya que la red gnutella tenía un sentido totalmente distinto. La idea era que el Network Manager pudiera pinguear cada cierto tiempo, configurado por Config File, para que se re-descubriera la red. Cada nodo (File Server) conocía y tenía una lista de nodos que estaban conectados a la red, y si el nodo con el que estaba conectado directamente se caía, ante una solicitud de PING, tenía que probar con siguiente nodo conocido.

Cuando el Cliente efectuaba un Request por su consola, la consulta no era por HTTP sino por protocolo IPC/IRC. Iba dirigida al Network Manager, quien primero consultaba (si estaba activada) al Cache Server si la consulta ya había sido efectuada -CACHE HIT-. La Cache guardaba los Response asociados a esos Requests. Y si daba CACHE MISS, o la Cache estaba desactivada, el pedido Request se transformaba en un Gnutella Package, y el Network Manager se la enviaba al File Server que tenía asociado, y éste lo distribuía tantas veces como el TTL del paquete estaba seteado previamente por el Network Manager (también por Config File).

La consulta a través de la red Gnutella tenía como objetivo que cada nodo File Server enviara la lista de archivos (de su file system local) que empezaran con el nombre solicitado por Request por parte del Cliente, y también los datos de sí mismo (IP y Puerto). De manera tal que, dado el TTL=N del paquete, a N File Servers les iba a llegar este pedido, e iban a enviar la respuesta al nodo anterior (que se la mandó), pero a la vez a re-distribuirla a los nodos que tuviera conectados a sí mismo.

Una vez que la información del pedido Request volvía al Network Manager, se armaba un paquete Response IPC/IRC con todos los datos de los archivos, por File Server, se actualizaba la Cache Server si estaba activada, y se enviaba de vuelta. Finalmente, el Cliente seleccionaba por consola que archivo quería descargar (previo a eso, la consola le mostraba un menú de opciones hermosamente ordenado) y para descargar ese archivo se creaba un nuevo Thread que se comunicaba por protocolo HTTP directamente con el File Server que tenía el archivo y lo descargaba. Magicoo.


También se me plantó un lagrimón, porque lo terminé y andaba genial. Pero en ese momento tuve otro lagrimón porque recursé igual xD

uh
aguante el emulaso