y de nuevo dll y el mercado - página 17
Está perdiendo oportunidades comerciales:
- Aplicaciones de trading gratuitas
- 8 000+ señales para copiar
- Noticias económicas para analizar los mercados financieros
Registro
Entrada
Usted acepta la política del sitio web y las condiciones de uso
Si no tiene cuenta de usuario, regístrese
http no tiene cabeceras -u o --output-file
pero todas las cabeceras se pasan como key:value separadas por \r\n (que es casi exactamente la cita de referencia)
curl tiene un interruptor que imprimirá toda la comunicación con el servidor (y todas las cabeceras) en detalle...
===
"lee mana, ellos gobiernan"
probablemente tengas razón, y la captura de pantalla de postman, donde el par de salida se escribe en la cabecera de la petición http se explica de alguna otra manera )
sospecho que seguimos hablando de lo mismo, pero con palabras diferentes )
¡y por favor, por favor, no más playsound() es comprensible, y el problema es completamente diferente! )))
La tarea consiste en realizar la autorización en la nube de IBM mediante WebRequest.
Por cierto, la salida al archivo sí llega a las cabeceras
No diría que todo fue tan claro con PlaySound )))) Resultó por ejemplo que a pesar de la documentación, el .wav se reproduce desde la carpeta Files, (sin la cual su proyecto podría cerrarse) y que los recursos dinámicos de EA no pueden llevar los archivos de sonido reproducidos, porque todo se guarda en uint.
En cuanto a la autorización en la nube de IBM con WebRequest, no sé más que la tuya aquí, hasta ahora... Necesito estudiar. Experimento... Llevará tiempo.
¡Mierda! Estoy atascado en los sindicatos. Webrequest devuelve una matriz dinámica de caracteres, y para almacenarla en un recurso, es necesario convertirla a uint. Esto no es un problema si se declara una unión, pero la unión sólo permite declarar arrays estáticos. No se puede enviar un array estático a webbrequest, porque el tamaño del archivo de retorno es indefinido.
WebBrequest debería quedar en el olvido como un mal sueño.
SocketRead lee en un array uchar, y luego puedes hacer lo que quieras con él. En los ejemplos de la documentación enlazada, que ya he citado dos veces, la obtención de la respuesta a través de HTTP se acaba de implementar. Modifícalo para adaptarlo a la tarea y voilá.
Ya es hora de olvidarse de la webrequest como un mal sueño.
SocketRead lee el array uchar y luego puedes hacer lo que quieras con él. En los ejemplos de la documentación enlazada, que ya he citado dos veces, se implementa la respuesta HTTP. Modifícalo para adaptarlo a la tarea, y voilá.
Estoy de acuerdo, hay que cavar en esta dirección. Aunque el problema de la autorización parece irresoluble, por alguna razón... Tal vez me equivoque de nuevo))).
Ya es hora de olvidarse de la webrequest como un mal sueño.
SocketRead lee el array uchar y luego puedes hacer lo que quieras con él. En los ejemplos de la documentación enlazada, que ya he citado dos veces, se implementa la respuesta HTTP. Modifícalo para adaptarlo a tu tarea y listo.
Webrequest, al igual que el socket para la transferencia de datos, utiliza la apertura de la conexión.
La webrequest crea una sesión implícitamente, con los sockets, establecemos explícitamente una conexión.
Así que en ambos casos, el canal para la transferencia de datos se abre primero de una manera u otra.
El socket es útil cuando necesitamos transferir datos durante mucho tiempo sin cerrar la conexión, entonces sí tiene sentido utilizarlo.
Pero si el socket se utiliza para una solicitud única, no tiene sentido.
Porque cada vez la solicitud creará una nueva conexión, lo que lleva tiempo.
Y para crear la conexión http según mis mediciones en C, de 100 milisegundos en adelante.
Encontré un programa que convierte el texto a .wav y va directamente a la carpeta Files.
Tanto el webrequest como el socket de datos utilizan la apertura de la conexión.
Webquest crea una sesión implícitamente, mientras que con los sockets establecemos explícitamente una conexión.
Así que en ambos casos, el canal para la transferencia de datos se abre primero de una manera u otra.
El socket es útil cuando necesitamos transferir datos durante mucho tiempo sin cerrar la conexión, entonces sí tiene sentido utilizarlo.
Pero si el socket se utiliza para una solicitud única, no tiene sentido.
Porque cada vez la solicitud creará una nueva conexión, lo que lleva tiempo.
Y para crear la conexión http según mis mediciones en C, a partir de 100 milisegundos.
¡Romano! ¡Eso es lo que realmente te faltaba! ¡Sientes que sabes y tienes práctica! )
No obstante, intentaré modificar WebRequest.
¡Romano! ¡Eso es lo que realmente faltaba! ¡Se puede sentir tanto el conocimiento como la práctica! )
Intentaré modificar WebRequest
Así que, pregúntale a Roman, cómo implementar la autorización en el servidor de IBM conWebRequest. ¡Esa es una pregunta clave!
Así que pregunte a Roman cómo hacer la autorización en el servidor de IBM conWebRequest. ¡Esta es la pregunta clave!
No me he metido en la pregunta, pero según tengo entendido, se utiliza una clave que se obtiene previamente en el sitio donde se envía la solicitud.
En este caso no es necesaria la autorización, la identificación se hace por clave.
Hay que fijarse bien en el ejemplo de la estructura de la solicitud en el sitio.
Según recuerdo de un ejemplo, se utiliza el cuerpo de la solicitud.
Es decir, las cabeceras son cabeceras, pero el texto se envía al cuerpo de la petición.