Wie kann ich aus der Ferne auf den Truthahn zugreifen? - Seite 9

 
Dann ist es nur noch eine Frage von Anfang und Ende :)
 

Genau das werden wir tun :)

 
Ich bin froh, dass ihr euch so anstrengt. Ich wünsche Ihnen viel Erfolg.
 
sergeev >>:

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

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

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


Im Allgemeinen ist es gar nicht so kompliziert. Sie haben die Bibliothek ws2_32.dll, aus der Sie Funktionen importieren

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

Dies sollte sowohl für den Client als auch für den Server ausreichend sein (vielleicht habe ich etwas übersehen, siehe MSDN). Sie nehmen ein Beispiel aus MSDN und übersetzen es in µl. Aber es ist nicht sehr gut, Sie werden blockierende Sockets verwenden, so dass Ihr Thread anhält und Sie nicht in der Lage sind, ihn auf dem Server zu bearbeiten.
 
SofTAA >>:
Только не очень хорошо получится, ты будешь использовать блокирующие сокеты соответственно поток у тебя встанет и обработку ты не сможешь вести на сервере.

mehr zu diesem Punkt. :)

1. Wie lange wird die Sperrung dauern?

2. was diese Sperre betrifft

2. die Alternative ohne Sperrung.

Im Allgemeinen habe ich einige Erfahrung in der Arbeit mit Sockets (ich entwickelte verteilte Computer, aber nicht mit api Methoden, sondern mit Hilfe von MFC-Klassen)

Ich hatte noch nie Probleme mit dem Sperren von Servern (d.h. Aufgabenverteiler), ich wusste nicht einmal davon.

Wann kann dies geschehen?

 

Soweit ich das verstanden habe, geht es um den synchronisierten Zugang.

 
sergeev >>:

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

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

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

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

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

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

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


Es macht keinen Unterschied, ob Sie direkt oder über MFC arbeiten, die Wurzeln liegen ohnehin in ws2_32.dll. Wenn Sie blockierende Sockets verwenden, wird der Server immer auf den Port hören und der entsprechende Thread wird immer blockiert. Leider wird Multithreading in µl nicht beachtet und auch nicht erwartet, so dass man dieses Problem nicht vermeiden kann, außer bei selbstgeschriebener Lib. Natürlich wird es keine derartigen Probleme mit dem Kunden geben. Wenn Sie also nur Daten von MT an eine Anwendung eines Drittanbieters senden möchten, können Sie dies über eine reine API implementieren.
 
xrust >>:

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


Ja, das ist genau richtig. Für den asynchronen Betrieb sind die Fähigkeiten der MCL eindeutig unzureichend.
 
SofTAA >>:


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

Der MT- oder EA-Thread wird also blockiert, weil der Socket in eine Endlosschleife des Abhörens eintritt?

Geht es hier um Zuhören?

 

Seien Sie nicht so streng mit MT, denn Multithreading ist immer noch vorhanden - die Indikatoren arbeiten im Terminal-Thread, die EAs und Skripte in einem eigenen Thread.
Der Orderkanal ist derselbe, so dass der EA das Terminal nicht verlangsamt oder nach den standardmäßigen 2,5 Minuten einen Timeout erhält...

Grund der Beschwerde: