Нужен лучший способ ожидания между отправкой и получением, UDPclient - PullRequest
Новая
       3

Нужен лучший способ ожидания между отправкой и получением, UDPclient

1 голос
/ 07 декабря 2010

Вот моя проблема:

У меня есть класс udp, который позволяет мне отправлять и получать данные с игрового сервера.

Но я обнаружил, что сервер разрешает только один запрос на 500 мс на клиента,поэтому, если я отправляю два запроса подряд, сервер отвечает только на первый, и у меня нет возможности узнать, что я не получу второй ответ.

Итак, я сделал Mutex для защитыотправить часть, когда я отправляю данные, я использую поток, чтобы заблокировать мьютекс 500 мс.

Этот класс используется потоком, поэтому я использую мьютекс.

Но на самом деле это не работаетХорошо, когда-нибудь получатель зависает.

Я просто хочу знать, есть ли у кого-нибудь лучший способ сделать это.

Спасибо и извините за мой английский.

ПРАВКА: Я не могу использовать протокол TCP, мне нужно сделать это с UDP.Мне также нужен оптимальный способ, мне нужно, чтобы получать данные как можно скорее в форму просмотра.Я наблюдаю за каждой отдельной темой в сети, которую я нашел в udp и threading, но не нахожу этот конкретный случай.

Ответы [ 3 ]

1 голос
/ 07 декабря 2010

Если вы знаете, что можете отправлять сообщения только с некоторой частотой, почему бы не блокировать вызовы. А потом спать в течение необходимого времени. 

class UDP {
  int _lastTime = 0;
  int MIN_DELAY = 500;

  public void send() {
    lock(this) {
      int duration = now() - _lastTime;
      if (duration < MIN_DELAY) {
        sleep(MIN_DELAY - duration);  
      }
      realSend();
      _lastTime = now();
    }
  }
}
1 голос
/ 07 декабря 2010

С UDP вы никогда не должны предполагать, что получите ответ на любое сообщение, которое вы отправите. Вы также не должны предполагать, что сообщение действительно будет получено или что несколько сообщений будут получены в том же порядке, в котором вы их отправили. Вот почему UDP действительно подходит только для протоколов, которые могут терпеть потерю информации. Если вы хотите сохранить целостность, вам нужно разрешить повторные попытки, и в этот момент вам, вероятно, было бы лучше использовать TCP (при условии, что у вас есть выбор в этом вопросе).

Без дополнительной информации о деталях протокола трудно рекомендовать хорошее решение. Если это простой стиль сообщения «опрос статуса», один из вариантов - просто отправлять сообщения опроса с фиксированным интервалом и обрабатывать ответы по мере их поступления, игнорируя любое отношение, которое могут иметь ответы к отправляемым сообщениям.

0 голосов
/ 07 декабря 2010

Как уже отмечали другие, нельзя предполагать, что UDP-сообщение будет доставлено.Это, вероятно, вызывает зависание вашего кода на приеме.Возможно, достаточно просто установить Socket's ReceiveTimeout для вашего приложения.

Или вы можете настроить (несколько более сложный) метод отправки сообщений в очередь, отправляя только одно каждые 500 мс.и повторять их через определенное время, пока вы не получите ответ.Если бы я шел по этому маршруту, я бы разработал следующие общие пункты:

  • Использование асинхронного UDP.
  • Создание структуры / класса для фактической информации для отправки / получения (скажем,, MsgObject), включая информацию о последней передаче.
  • Используйте этот объект MsgObject в качестве объекта AsyncState.
  • Управление потокобезопасной очередью / списком всех активных объектов MsgObject.то есть сообщения, которые были запрошены для отправки, но ответа не было получено.
  • Имейте простой таймер для периодической проверки очереди / списка (не чаще, чем каждые 500 мс в вашем случае), чтобы увидеть, есть ли новыйсообщение для отправки или то, которое необходимо повторно отправить.
  • В функции асинхронного приема удалите объект MsgObject, получивший ответ из очереди / списка.
...