Come posso accedere alla tacchina da remoto? - pagina 9

Nuovo commento
 
Poi è solo una questione di iniziare e finire :)
 

Questo è quello che faremo :)

 
Sono contento che vi stiate spingendo. Vi auguro ogni successo.
 
sergeev >>:

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

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

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


In generale, non è così complicato. Avete la libreria ws2_32.dll, importate funzioni da essa

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

Questo dovrebbe essere sufficiente sia per il client che per il server (potrei essermi perso qualcosa, vedi MSDN). Si prende un esempio da MSDN e lo si traduce in µl. Ma non è molto buono, userete socket bloccanti, quindi il vostro thread si fermerà e non sarete in grado di gestirlo sul server.
 
SofTAA >>:
Только не очень хорошо получится, ты будешь использовать блокирующие сокеты соответственно поток у тебя встанет и обработку ты не сможешь вести на сервере.

più su questo punto. :)

1. quanto tempo ci vorrà per il blocco?

2. Cosa colpisce questo bloccaggio?

2. l'alternativa senza blocco.

In generale, ho una certa esperienza nel lavorare con i socket (ho sviluppato il calcolo distribuito, ma non con metodi api, ma con l'aiuto di classi MFC)

Non ho mai avuto problemi con il blocco del server (cioè il distributore di compiti), non ne ero nemmeno a conoscenza.

quando può accadere?

 

Per quanto ho capito, stiamo parlando di accesso sincronizzato.

 
sergeev >>:

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

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

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

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

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

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

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


Non fa differenza se lavorate direttamente o tramite MFC, le radici sono comunque in ws2_32.dll. Se usate socket bloccanti, allora il server ascolterà sempre la porta e di conseguenza il thread sarà sempre bloccato. Sfortunatamente il multithreading in µl non è osservato e non è previsto, quindi non si può evitare questo problema tranne che per le lib scritte in proprio. Naturalmente non ci saranno questi problemi con il cliente. Quindi, se si inviano solo dati da MT a un'applicazione di terze parti, si può implementare usando l'api pura.
 
xrust >>:

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


Sì, è esattamente così. Per il funzionamento asincrono, le capacità della MCL sono chiaramente insufficienti.
 
SofTAA >>:


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

Quindi il thread MT o EA sarà bloccato perché il socket entra in un ciclo infinito di ascolto?

si tratta di ascoltare?

 

Non essere così duro con MT, un po' di multithreading è ancora presente - gli indicatori lavorano nel thread del terminale, e gli EA e gli script nel loro thread separato.
Il canale degli ordini è lo stesso, quindi l'EA non rallenterà il terminale, né otterrà un timeout da esso dopo i 2,5 minuti standard...

12345678910
Nuovo commento