Mensajes

Yo utilizaría cURL, aquí tienes un ejemplo:

http://curl.haxx.se/libcurl/c/fileupload.html

Coloca el código y el error que te arroja ESE código.

EDIT:

Tutorial con Dev C++ http://darkchicles.wordpress.com/2011/07/18/crear-dll-con-devc/

Hola gracias por los comentarios, en realidad me estoy planteando, montarlo en java en vez de en c que por lo visto tambien puedo hacerlo correr en linux, ya que veo que en java practicamente todas estas cosas de bajo nivel estan axtraidas. no quiero hacerme la vida imposible con el servidor de sockets porque luego me quedara toda la programacion por parte del cliente/juego que es donde quiero invertir el tiempo.

Osea me gustaria un lenguaje parecido a algo que ya conociera de alto nivel como js, php, as3
(ya monte un servidor de sockets en php y no me convencio, tambien lo monte en adobe air pero no puedo instarlo en el vps porque ya no tiene soporte para linux, aunque podria instalarlo en uno windows pero el precio se dispara)

Asi que, que me recomiendan para crear un proceso de sockets para linux? java o c++?

Lo más parecido a lo que mencionas es node.js y si quieres más abstracción y tus opciones son Java y C++ te recomiendo que te vayas por Java. Sin embargo, node.js se programa utilizando javascript prácticamente.

Creo que lo que quieres hacer es un Sniffer, aquí te dejo un código de uno:

http://www.binarytides.com/packet-sniffer-code-c-linux/

Para poderte ayudar, sería bueno que publicaras el código que te da error al compilar y exactamente que errores te da

Esto está mal

Código (c) [Seleccionar] Expandir

message = "<?xml version=\"1.0\"?><!DOCTYPE cross-domainpolicy- SYSTEM \"http://www.adobe.com/xml/dtds/crossdomain.dtd\"><cross-domain-policy><allow-access-from domain=\"*\" to-ports=\"*\" /></cross-domain-policy>";

Declaras un puntero a message pero no especificas tamaño, y por lo que he visto, message siempre tiene ese contenido, asi que prueba esto:
...

En realidad, eso no está mal... la cadena "<?xml version=\"1.0\"?><!DOCTYPE cross-domainpolicy- SYSTEM \"http://www.adobe.com/xml/dtds/crossdomain.dtd\"><cross-domain-policy><allow-access-from domain=\"*\" to-ports=\"*\" /></cross-domain-policy>" es un literal y el apuntador message apunta a este. Al declarar una cadena en C entre comillas dobles automáticamente se agrega el caracter nulo (\0) al final, por lo tanto se pueden utilizar las funciones de la librería string tales como strlen y strcmp . Exactamente no se cual es el problema que tienes, pero sin duda alguna esa declaración no es parte del problema.

Por otra parte, dependiendo de lo que quieras hacer, puedes utlizar node.js o Python y te evitarás problemas con detalles de C

Puedes crear una cabecera para cada registro donde te indique el tamaño real del registro, es decir, que sea una estructura con un campo donde te de el tamaño en bytes del registro real y así puedes ir leyendo hasta almacenar todos los registros en un arreglo dinámico.

No, no hay una función que te permita hacer eso, lo más común es posicionarte al final de archivo y con la función ftell obtienes la posición actual que en este caso sería el tamaño del archivo en bytes.

Puedes obtener el tamaño del fichero, luego esto lo divides entre el tamaño del registro y te dará la cantidad de registros que hay en el fichero, es decir, el tamaño de tu arreglo.

Ejemplo: Supongamos que tu estructura pesa 4 bytes y el fichero pesa 12 bytes quiere decir que en el fichero hay 3 registros.

Sin duda por lo que he leído la pila (stack) es más rápida que el montón (heap), ahora bien te voy a traducir algo que leí aquí http://stackoverflow.com/questions/3455987/comparison-of-access-performance-of-data-in-heap-and-stack

• Una ventaja de usar la pila es que es más propensa a estar en la caché a diferencia de un bloque recién reservado en el montón, pero esto sería en la primera ejecución unicament.


• Reservar memoria en la pila es más "económico" que en el montón porque en la pila simplemente es incrementar el SP (Stack pointer o apuntador de pila) y en el montón se hace de una manera más compleja (si no me equivoco, con listas).


• Uno de los problemas de usar el montón es la fragmentación y el manejo de la memoria debe hacerse de manera manual.

Sin embargo, el rendimiento de la aplicación no lo define si usas el heap o el stack, ambos tienen su uso, se recomienda que para datos pequeños usar el stack, pero para grandes cantidades de datos usar el heap.

Espero que te sirva la respuesta.