¿Cómo puedo acceder al pavo a distancia? - página 9

Nuevo comentario
 
Entonces sólo es cuestión de empezar y terminar :)
 

Eso es lo que haremos :)

 
Me alegro de que os esforcéis. Le deseo mucho éxito.
 
sergeev >>:

про winsock.dll как раз и идёт речь.

имеется ввиду, что нежелательно использовать свои самописные либы. а виндовые без проблем.

Если не сложно, поделитесь ссылками или кодами без классов (обверток). желательно чистое апи.


En general, no es tan complicado. Tienes la biblioteca ws2_32.dll, importas funciones de ella

int WSAStartup, WSACleanup, socket, bind, connect, listen, accept, recv, send, closesocket.

Esto debería ser suficiente tanto para el cliente como para el servidor (puede que me haya olvidado de algo, véase MSDN). Coge un ejemplo de MSDN y tradúcelo a µl. Pero no es muy bueno, usarás sockets bloqueantes, por lo que tu hilo se detendrá y no podrás manejarlo en el servidor.
 
SofTAA >>:
Только не очень хорошо получится, ты будешь использовать блокирующие сокеты соответственно поток у тебя встанет и обработку ты не сможешь вести на сервере.

más sobre este punto. :)

1. ¿cuánto tiempo durará el bloqueo?

2. A qué afecta este cierre

2. la alternativa sin bloqueo.

En general, tengo algo de experiencia en el trabajo con sockets (desarrollé computación distribuida, pero no con métodos api, sino con la ayuda de clases MFC)

nunca he tenido problemas con el bloqueo del servidor (es decir, el distribuidor de tareas), ni siquiera lo conocía.

¿cuándo puede ocurrir esto?

 

Según tengo entendido, se trata de un acceso sincronizado.

 
sergeev >>:

с этого места поподробнее. :)

1. на как долго произойдет блокирование?

2, что затрагивает эта блокировка

2. альтернатива без блокирования.

вообще практика работы с сокетами есть (разрабатывал распределенные вычисления, но не апи методами а классами MFC)

с блокировкой сервака (то есть компа-рассыльщика заданий) проблем не было и даже не знал про это.

это в каких случаях может проявится?


No hay diferencia si se trabaja directamente o a través de MFC, las raíces están en ws2_32.dll de todos modos. Si utiliza sockets de bloqueo, el servidor siempre escuchará el puerto y, por lo tanto, el hilo siempre se bloqueará. Desgraciadamente, el multithreading en µl no se observa ni se espera, por lo que no se puede evitar este problema salvo en el caso de las librerías autoescritas. Naturalmente, no habrá esos problemas con el cliente. Así que si sólo envía datos desde MT a una aplicación de terceros, puede implementarlo usando una api pura.
 
xrust >>:

Насколько я понял речь идет о синхронном доступе.


Sí, eso es exactamente. Para el funcionamiento asíncrono, las capacidades de la ACM son claramente insuficientes.
 
SofTAA >>:


Если использовать блокирующие сокеты то сервер постоянно будет слушать порт и соответственно поток всегда будет заблокирован.

Entonces, ¿el hilo de MT o EA se bloqueará porque el socket entra en un bucle interminable de escucha?

¿se trata de escuchar?

 

No seas tan duro con MT, el multithreading todavía está presente - los indicadores trabajan en el hilo de la terminal, y los EAs y los scripts en su propio hilo separado.
El canal de órdenes es el mismo, por lo que el EA no ralentizará el terminal, ni obtendrá un timeout del mismo tras los 2,5 minutos estándar...

12345678910
Nuevo comentario