Comment puis-je accéder à la dinde à distance ? - page 9

Nouveau commentaire
 
Ensuite, il ne reste plus qu'à commencer et à terminer :)
 

C'est ce que nous ferons :)

 
Je suis content que vous vous surpassiez. Je vous souhaite beaucoup de succès.
 
sergeev >>:

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

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

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


En général, ce n'est pas si compliqué. Vous avez la bibliothèque ws2_32.dll, vous importez des fonctions de celle-ci

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

Cela devrait être suffisant pour le client et le serveur (j'ai peut-être oublié quelque chose, voir MSDN). Vous prenez un exemple de MSDN et le traduisez en µl. Mais ce n'est pas très bon, vous utiliserez des sockets bloquants, donc votre thread s'arrêtera et vous ne serez pas en mesure de le gérer sur le serveur.
 
SofTAA >>:
Только не очень хорошо получится, ты будешь использовать блокирующие сокеты соответственно поток у тебя встанет и обработку ты не сможешь вести на сервере.

plus sur ce point. :)

1. Combien de temps durera le blocage ?

2. ce que cette fermeture affecte

2. l'alternative sans blocage.

En général, j'ai une certaine expérience du travail avec les sockets (j'ai développé l'informatique distribuée, mais pas avec des méthodes api, mais à l'aide de classes MFC).

je n'ai jamais eu de problèmes avec le verrouillage des serveurs (c'est-à-dire le distributeur de tâches), je ne le savais même pas.

Quand cela peut-il arriver ?

 

D'après ce que je comprends, nous parlons d'accès synchronisé.

 
sergeev >>:

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

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

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

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

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

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

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


Cela ne fait aucune différence si vous travaillez directement ou via MFC, les racines sont dans ws2_32.dll de toute façon. Si vous utilisez des sockets bloquants, le serveur écoutera toujours le port et le thread correspondant sera toujours bloqué. Malheureusement, le multithreading dans µl n'est pas observé et n'est pas attendu, donc vous ne pouvez pas éviter ce problème sauf pour les librairies écrites par vous-même. Naturellement, il n'y aura pas de tels problèmes avec le client. Ainsi, si vous envoyez simplement des données de MT à une application tierce, vous pouvez l'implémenter en utilisant une api pure.
 
xrust >>:

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


Oui, c'est exactement ça. Pour un fonctionnement asynchrone, les capacités du MCL sont clairement insuffisantes.
 
SofTAA >>:


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

Ainsi, le thread MT ou EA sera bloqué parce que le socket entre dans une boucle d'écoute sans fin ?

s'agit-il d'écouter ?

 

Ne soyez pas si dur avec MT, le multithreading est toujours présent - les indicateurs fonctionnent dans le fil du terminal, et les EA et les scripts dans leur propre fil séparé.
Le canal d'ordre est le même, donc l'EA ne ralentira pas le terminal, ou n'obtiendra pas un timeout de sa part après les 2.5 minutes standard...

12345678910
Nouveau commentaire