Como posso acessar o peru remotamente? - página 9

Novo comentário
 
Depois é só uma questão de começar e terminar :)
 

Isso é o que faremos :)

 
Estou feliz que vocês estão se esforçando. Desejo-lhe muito sucesso.
 
sergeev >>:

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

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

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


Em geral, não é tão complicado assim. Você tem a biblioteca ws2_32.dll, você importa funções dela

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

Isto deve ser suficiente tanto para o cliente quanto para o servidor (eu poderia ter perdido algo, ver MSDN). Você pega um exemplo do MSDN e o traduz para µl. Mas não é muito bom, você usará soquetes de bloqueio, então sua rosca vai parar e você não será capaz de lidar com ela no servidor.
 
SofTAA >>:
Только не очень хорошо получится, ты будешь использовать блокирующие сокеты соответственно поток у тебя встанет и обработку ты не сможешь вести на сервере.

mais sobre esse ponto. :)

1. Quanto tempo demorará o bloqueio?

2. o que este bloqueio afeta

2. A alternativa sem bloqueio.

Em geral, tenho alguma experiência em trabalhar com soquetes (desenvolvi computação distribuída, mas não com métodos api, mas com a ajuda de classes MFC)

nunca tive nenhum problema com o travamento do servidor (ou seja, distribuidor de tarefas), nem mesmo sabia disso.

quando isso pode acontecer?

 

Tanto quanto eu entendo, estamos falando de acesso sincronizado.

 
sergeev >>:

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

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

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

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

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

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

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


Não faz diferença se você trabalha diretamente ou via MFC, as raízes estão na ws2_32.dll de qualquer forma. Se você usar tomadas de bloqueio, o servidor sempre escutará a porta e, conseqüentemente, a linha será sempre bloqueada. Infelizmente, a multithreading em µl não é observada e não é esperada, portanto, não se pode evitar este problema, exceto no que diz respeito à libra autoescrita. Naturalmente, não haverá tais problemas com o cliente. Portanto, se você simplesmente envia dados da MT para uma aplicação de terceiros, você pode implementá-los usando api pura.
 
xrust >>:

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


Sim, é exatamente isso. Para a operação assíncrona, as capacidades do MCL são claramente insuficientes.
 
SofTAA >>:


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

Então a linha MT ou EA será bloqueada porque a tomada entra em um loop infinito de escuta?

Trata-se de ouvir?

 

Não seja tão duro com a MT, alguns multithreading ainda estão presentes - indicadores trabalham no fio terminal, e EAs e scripts em seu próprio fio separado.
O canal de pedido é o mesmo, por isso o EA não vai desacelerar o terminal, ou obter um timeout dele após os 2,5 minutos padrão...

12345678910
Novo comentário