readline

en mi server uso;
--------------------------
en las entradas
entrada = new BufferedReader(new InputStreamReader(this.socket.getInputStream()));

en las salidas
salida = new PrintStream(this.socket.getOutputStream());

en el cliente
--------------------
entradas
this.bufferInput = new BufferedReader(new InputStreamReader(socket.getInputStream()));
salidad
this.out = new PrintStream(socket.getOutputStream());

aqui envio y recibo tramas sin problemas, porque mi cliente son java y mi server es java, pero mis clientes en C solo me contestas si le añado
/n/r esto es normal ?? o debo usar alguna variante diferente de inputStreamreader o getOutputStream ????

Opciones de visualización de comentarios

Seleccione la forma que prefiera para mostrar los comentarios y haga clic en «Guardar las opciones» para activar los cambios.

No leas "texto" por lineas,

No leas "texto" por lineas, ( que es lo que lee tu reader ) intenta leyendo todo el stream sin importar lo que envies son líneas o no.

Si con tu servidor estas luego leyendo con BufferedReader.readLine() ese "readLine" espera una línea para continuar, la cual solo se manda cuando escribe \n ( en windows y \n en LinUnix )

Intenta leer todo el stream

Revisa este c'odigo

Imagen de ezamudio

líneas

Como dice Oscar, los métodos de esos objetos que usas para leer y escribir por líneas lo que hacen es pegar un cambio de línea al final (en la escritura) y leer datos hasta encontrar un cambio de línea (en la lectura). En C no existe equivalente de println, tienes que enviar \n al final o \n\r (o \r\n algo así) en Windows. Son simples métodos de conveniencia pero bien podrías usar algún otro delimitador, aunque en ese caso tendrías que implementar tus propias rutinas de lectura que detecten el delimitador para devolver los datos hasta ese punto.

Si quieres tener comunicación más sofisticada entre C y Java puedes usar los protocol buffers de Google...

a cual te refieres...

 

o lo manejo con DataInputStream ???? o como deberia leer todo el stream, lo ideal seria hacerlo de le mejor manera siempre buscando la maxima eficiencia recuerda que que el server debe soportar entre 800 y 1600 maquinas conectandose a lo bestia todo el dia y en horas pico no se entrañe que todas las maquinas manden peticones al mismo tiempo.

Imagen de ezamudio

protocolo?

No podemos decirte qué hacer sin saber más. Si estás usando HTTP por ejemplo, puedes leer todo el stream si en el encabezado viene la longitud de los datos que vas a recibir. Lees el encabezado y si te dice que te van a enviar 1655 bytes pues creas un arreglo de 1655 bytes y lo tratas de leer completo, aunque tal vez no llegue todo en una sola lectura, el algoritmo es algo así:

 

Y ya con los datos completos ahora sí puedes procesar como quieras: convertirlos a cadena, separar por líneas o comas o tab o lo que sea.

En general, la recomendación es que si tienes muchas máquinas conectándose pues hay que atender cada petición lo más pronto posible, y por eso cada transacción debería ser lo más breve posible; los clientes abren una conexión, envían datos, cierran la conexión; y así el server acepta una conexión, recibe una petición, la despacha y se olvida de la conexión.

Sospecho que esto está relacionado con otro post (no sé por qué decidiste repartir el problema en dos posts distintos) donde mencionaste que los clientes son conexiones por celular. Si de plano necesitas mantener la conexión abierta, entonces tal vez en el server deberías usar java.nio en vez de java.io para poder manejar un número grande de conexiones con pocos hilos. Ese esquema es muy útil para manejar conexiones inactivas, porque en el hilo principal tienes un ciclo donde recibes notificaciones cuando una conexión recibe datos o cuando llega una nueva conexión, y puedes mandarla a procesar en un threadpool pero cuando esa transacción termine, la conexión puede seguir abierta y recibirás una nueva notificación en el hilo principal cuando llegue otra transacción. Eso te permite mantener la conexión abierta pero no ocupará ningún hilo mientras no haya actividad en la misma.