Menú

Mostrar Mensajes

Esta sección te permite ver todos los mensajes escritos por este usuario. Ten en cuenta que sólo puedes ver los mensajes escritos en zonas a las que tienes acceso en este momento.

Mostrar Mensajes Menú

Mensajes - eferion

#831
Vale, espera... una cosa... qué pinta ahí la constante WIDTH??

square_x = xLeft + (x/WIDTH)*(xRight-xLeft);

se supone que x/WIDTH te va a dar el desplazamiento en porcentaje... eso lo multiplicas por la escala real y te debería dar las coordenadas reales, cierto??

También deberías mirar el tipo de las variables... si estás operando con int vas a tener problemas con los redondeos... sobretodo si las operaciones de división se ejecutan antes que las de producto.
#832
Solo una cosa más.

UDP no tiene por qué ser bidireccional. UDP se basa en el envío de tramas de datos sin control de flujo alguno... por lo que perfectamente un cliente podría enviar datos a un servidor sin recibir ( y sin esperar recibirla ) respuesta alguna.

Otra cosa es el protocolo TCP, que este si asegura tanto la entrega como el orden de las tramas... pero también es más pesado y lento.
#833
y no tendrás por algún casual los tipos de las variables implicadas, verdad??

square_x = xLeft + (x)*(abs(xRight)+abs(xLeft))/WIDTH;

mmmm

Hasta donde llego el ancho de la ventana debería calcularse como xRight-xLeft... ya que la suma puede darte de todo menos la anchura de la ventana.

Por tanto, square_x debería calcularse así:

square_x = xLeft + x*(abs(xRight)-abs(xLeft))/WIDTH;

Con la coordenada vertical te pasa lo mismo.

Como no aparece el algoritmo, puede que también tengas problemas al calcular xLeft y yBot.

Un saludo
#834
Cita de: kotora en 29 Octubre 2013, 16:16 PM
Primera pregunta:

¿Quien hace de cliente? yo diría por lo que he leído que de cliente hará el lado de Windows.

Todo depende de lo que diga el protocolo. Entiendo que si la comunicación es unidireccional ( detalle que me resulta demasiado curioso, ) el servidor debería ser forzosamente el destinatario de los mensajes... pero lo que te digo, la clave está en lo que aparezca en la especificación del protocolo.

Cita de: kotora en 29 Octubre 2013, 16:16 PM
Segunda....:

¿Puedo usar C# en lado windows y C en lado Linux?

La comunicación por sockets no entiende de lenguajes de programación. Una trama enviada por una red no es más que un flujo binario de datos.

Lo que sí es necesario es que tanto cliente como servidor "hablen" el mismo lenguaje, es decir, que se rijan por las mismas reglas de comunicación ( es decir, el protocolo de comunicación ).

Dicho de otra forma, cuando tú estás preguntando algo en este foro, lo que necesitas es una respuesta... te da igual si quien te responde es un hombre, una mujer, un niño, un perro o un despertador... te da igual siempre y cuando la respuesta sea satisfactoria. Es una analogía un poco extravagante pero sirve para plasmar la idea.

Y contestando de forma directa, SI, puedes utilizar el lenguaje que te de la gana en cada extremo de la comunicación.
#835
Esto va en la sección de .NET.

Aunque sea C++, no es nativo, sino que corre bajo .NET
#836
Si ya tienes una clase stack y otra queue... para que quieres adaptar list??
#837
En primer lugar, acostúmbrate a etiquetar el código... al escribir un mensaje verás que hay un combobox que dice "GeSHi". Está en la parte derecha encima del combo de "Cambiar Color". Si despliegas el combo GeSHi y eliges c o c++ te aparecerán las etiquetas entre las que debes introducir tu código para que sea mínimamente legible.

En segundo lugar:


while (resultat <= 21)
{
  if (num>=1 && num<=5)
  {
    scanf("%d", &num);
    resultat = resultat + num;
  }
  else if (num > 5)
  {
    printf("No se pueden introducir numeros mayores a 5 ni menores a 1\n");
    scanf("%d", &num);
  }
}


Vamos a ver... este código solo te va a pedir un nuevo número si el anterior está entre 1 y 5. Si metes un 6, por ejemplo, no te va a pedir nuevos números... pero como la suma será inferior a 21 no vas a salir del bucle principal luego el programa se queda atascado.

No se por qué te has obsesionado con comprobar el valor antes de pedírselo al usuario. Con lo sencillo que es hacerlo en el orden lógico, que es el inverso. Esto es, primero pedir el dato al usuario y, después, comprobar el valor que éste ha introducido:


while (resultat <= 21)
{
  // primero le pedimos el dato al usuario
  scanf("%d", &num);

  // despues hacemos las comprobaciones
  if (num>=1 && num<=5)
  {
    resultat = resultat + num;
  }
  else if (num > 5)
  {
    printf("No se pueden introducir numeros mayores a 5 ni menores a 1\n");
    // Y de paso eliminamos esta linea que sobra.
    // Es codigo duplicado y nos da una pista de que algo no esta bien programado
    //scanf("%d", &num);
  }
}
#838
Busca códigos para sacar "capturas de pantalla".

Eso si, ten en cuenta que los sistemas operativos modernos configuran la salida de vídeo en modo gráfico y eso hace que en dicha memoria no te encuentres caracteres... sino información de pixels... no vas a poder "leer" un carácter de dicha captura salvo que utilices algún sistema de reconocimiento de imágenes.
#839
Cita de: Maurice_Lupin en 21 Octubre 2013, 01:34 AM
Me recuerda al caso de las zonas hotspot que utilizan el cifrado md5.
La ventana de login cifra el pass antes de enviarlo al servidor, solución snifear a un usuario y guardar el hash y luego modificar la ventana de login para que sólo envie el hash.

Saludos.

Si snifeas a un usuario te da igual si la ventana cifra los datos o no... básicamente ya estás interceptando la petición que le manda el cliente al servidor y eso es todo lo que necesitas para crackear el proceso.

Para evitar problemas de este tipo habría que enviar este tipo de peticiones por una conexión segura con ssl, por ejemplo.
#840
Cita de: csp en 24 Octubre 2013, 22:48 PM
eferion: Podrías darme una idea de como hacer algo así?

algo como que??