Что Вы используете при необходимости в надежном UDP?
Даже у меня было подобное требование - вызовите веб-сервис, если он не работает, повторите попытку 3 раза. Если это не удается даже после этих многочисленных испытаний, отправьте уведомление по электронной почте. После многопользовательской игры, anyMatch() пришел как спаситель. Мой пример кода выглядит следующим образом. В следующем примере, если метод webServiceCall возвращает true в первой итерации, поток не выполняет итерацию по мере того, как мы вызвали anyMatch(). Я считаю, это то, что вы ищете.
import java.util.stream.IntStream;
import io.netty.util.internal.ThreadLocalRandom;
class TrialStreamMatch {
public static void main(String[] args) {
if(!IntStream.range(1,3).anyMatch(integ -> webServiceCall(integ))){
//Code for sending email notifications
}
}
public static boolean webServiceCall(int i){
//For time being, I have written a code for generating boolean randomly
//This whole piece needs to be replaced by actual web-service client code
boolean bool = ThreadLocalRandom.current().nextBoolean();
System.out.println("Iteration index :: "+i+" bool :: "+bool);
//Return success status -- true or false
return bool;
}
10 ответов
Трудно ответить на этот вопрос без некоторой дополнительной информации о домене проблемы. Например, какой объем данных Вы используете? Как часто? Какова природа данных? (например, действительно ли это уникально, один от данных? Или действительно ли это - поток демонстрационных данных? и т.д.), Для какой платформы Вы разрабатываете? (например, рабочий стол/сервер/встроенный) Для определения то, под чем Вы подразумеваете "слишком медленный", какую сетевую среду передачи Вы используете?
, Но в (очень!) общие термины я думаю, что Вы оказываетесь перед необходимостью пытаться действительно трудно победить tcp для скорости, если Вы не можете сделать некоторые трудные предположения о данных, что Вы пытаетесь отправить.
, Например, если данные, которые Вы пытаетесь отправить, таковы, что можно терпеть потерю единственного пакета (например, регулярно выбираемые данные, где частота дискретизации много раз выше, чем пропускная способность сигнала) тогда можно, вероятно, пожертвовать некоторой надежностью передачи путем обеспечения, что можно обнаружить повреждение данных (например, с помощью хорошего crc)
, Но если Вы не можете терпеть потерю единственного пакета, тогда Вы оказываетесь перед необходимостью начинать представлять типы методов для надежности, которую уже имеет tcp. И, не включая разумный объем работы, можно найти, что Вы начинаете встраивать те элементы в решение пространства пользователя со всеми свойственными проблемами скорости для движения с ним.
Вы рассматривали сжатие Ваших данных?
Как указано выше, мы испытываем недостаток в информации о точном характере Вашей проблемы, но сжатие данных для переноса их могло помочь.
Как другие указали, Ваш вопрос является очень общим, и 'быстрее' ли что-то, чем TCP во многом зависит от типа приложения.
TCP обычно с такой скоростью, как это добирается для надежной потоковой передачи данных от одного хоста до другого. Однако, если Ваше приложение делает много маленьких пакетов трафика и ожидающий ответов, UDP может быть более соответствующим для уменьшения задержки.
существует легкий второй план. алгоритм Nagle является частью TCP, который помогает гарантировать, что отправитель не сокрушает получатель большого потока данных, приводящих к перегрузке и потере пакетов.
при необходимости в надежном чтобы доставка TCP, и также быстрый ответ UDP, и не должны волноваться о перегрузке от отправки больших потоков данных, можно отключить алгоритм Nagle:
int opt = -1;
if (setsockopt(sock_fd, IPPROTO_TCP, TCP_NODELAY, (char *)&opt, sizeof(opt)))
printf("Error disabling Nagle's algorithm.\n");
, Если у Вас есть ситуация, где соединение TCP является потенциально слишком медленным и UDP 'соединение' потенциально слишком ненадежен, что Вы используете? Там существуют различные стандартные надежные протоколы UDP, какие события Вы имеете с ними?
ключевое слово в Вашем предложении 'потенциально'. Я думаю, что действительно необходимо доказать себе, что TCP является, на самом деле, слишком медленным для Ваших потребностей при необходимости в надежности в протоколе.
, Если Вы хотите вытащить надежность из UDP тогда, Вы в основном собираетесь быть перереализацией некоторых функций TCP сверху UDP, который, вероятно, сделает вещи медленнее, чем просто использование TCP во-первых.
ENET - http://enet.bespin.org/
я работал с ENET как надежный протокол UDP и записал асинхронным сокетам дружественную версию для моего клиента, который использует его в их серверах. Это работает вполне приятно, но мне не нравятся издержки, которые одноранговый узел для пиринга с ping добавляет к в других отношениях неактивным соединениям; когда у Вас есть много соединений, проверяющих с помощью ping-запросов всех их, регулярно большая занятая работа.
ENET дает Вам опцию отправить несколько 'каналов' данных и для данных, отправленных, чтобы быть ненадежным, надежным или упорядоченным. Это также включает вышеупомянутый одноранговый узел для пиринга с ping, который действует как поддержание.
RUDP - Надежный Протокол пользовательских дейтаграмм
Это обеспечивает:
- Подтверждение полученных пакетов
- Работа с окнами и управление перегрузкой
- Повторная передача потерянных пакетов
- Сверхбуферизация (Быстрее, чем потоковая передача в режиме реального времени)
Это кажется немного более настраивающимся относительно содержания alives тогда ENet, но это не дает Вам как многие опции (т.е. все данные надежны и упорядочиваются не только биты, которые Вы решаете, должен быть). Это выглядит довольно прямым для реализации.
Что относительно SCTP. Это - стандартный протокол IETF (RFC 4960)
, Это имеет большую возможность, которая могла помочь для скорости.
Обновление: сравнение между TCP и SCTP показывает, что действия сопоставимы, если два интерфейса не могут использоваться.
Обновление: хорошая вводная статья .
У нас есть некоторые клиенты военной промышленности, которые используют UDT (основанная на UDP Передача данных) (см. http://udt.sourceforge.net/ ), и очень довольны им. Я вижу, что это, имеет дружественную лицензию BSD также.
Возможно, вам будут полезны RFC 5405 , «Рекомендации по использованию одноадресной передачи UDP для разработчиков приложений».
Протокол DCCP, стандартизированный в RFC 4340 , «Протокол управления перегрузкой дейтаграмм» может быть тем, что вы ищете.
Кажется, реализован в Linux .