How do I access the turkey remotely? - page 9

New comment
 
Then it's just a matter of starting and finishing :)
 

That's what we'll do :)

 
I'm glad you guys are pushing yourselves. I wish you every success.
 
sergeev >>:

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

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

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


In general, it's not that complicated. You have library ws2_32.dll, you import functions from it

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

This should be enough for both client and server (I might have missed something, see MSDN). You take an example from MSDN and translate it to µl. But it's not very good, you will use blocking sockets, so your thread will stop and you won't be able to process it on the server.
 
SofTAA >>:
Только не очень хорошо получится, ты будешь использовать блокирующие сокеты соответственно поток у тебя встанет и обработку ты не сможешь вести на сервере.

more on that point. :)

1. how long will the blocking take?

2. What this locking affects

2. the alternative without blocking.

In general, I have some experience in working with sockets (I developed distributed computing, but not with api methods, but with the help of MFC classes)

i have never had any problems with server locking (i.e. task distributor), i didn't even know about it.

when can this happen?

 

As far as I understand, we are talking about synchronised access.

 
sergeev >>:

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

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

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

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

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

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

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


It makes no difference if you work directly or via MFC, the roots are in ws2_32.dll anyway. If you use blocking sockets then server will always listen to port and accordingly thread will always be blocked. Unfortunately multithreading in µl is not observed and not expected, so you can't avoid this problem except for self-written lib. Naturally there will be no such problems with the client. So if you just send data from MT to a third-party application, you can implement it using pure api.
 
xrust >>:

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


Yes, that's exactly right. For asynchronous operation, the MCL's capabilities are clearly insufficient.
 
SofTAA >>:


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

So the MT or EA thread will be blocked because the socket enters an infinite loop of listening?

is this about listening?

 

Don't be so hard on MT some multithreading is still present - indicators work in the terminal thread, and EAs and scripts in their own separate thread.
The order channel is the same, so the EA will not slow down the terminal, or get a timeout from it after the standard 2.5 minutes...

12345678910
New comment