Почему java.nio.SocketChannel не отправляет данные (Jdiameter)?

Question

Почему java.nio.SocketChannel не отправляет данные (Jdiameter)?

1

Я создаю клиент и сервер с простым диаметром (ссылка на источники). Клиент должен отправлять сообщения 10000 ccr, но в wirehark я вижу только ~ 300 ccr сообщений. Другие сообщения накладывали таймауты на клиента. Я запускаю сервер и клиент на разных компьютерах с окнами 7. Я нашел в строке источников JDiameter, где jdiameter sended ccr (строка 280), и я думаю, в случае, если отправка буфера сокета полна ccr not sended. Я добавляю перед строкой 280 этот код

while(bytes.hasRemaining())

Клиент отправил ~ 9900 ccr, но очень медленно. Я протестировал клиента на другом сервере с диагнозом wroted на c++, клиент (по jdiameter без моих изменений) отправил ~ 7000 ccr, но этот сервер размещался на debian.

Я не знаю, как решить эту проблему, спасибо за любую помощь.

MadCrank 18 март 2014, в 12:55

Источник

Теги:

java

sockets

diameter-protocol

restcomm

mobicents

1 ответ

Ещё вопросы

user207421 · Answer 1 · 2014-03-18T09-53-00.000Z

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

Так что ускорьте приемник.

NB В неблокирующем режиме, просто цикл вокруг вызова write() когда он возвращает ноль, не является адекватным. Если write() возвращает ноль, вы должны:

OP_READ регистрацию канала для OP_READ и зарегистрируйте его для OP_WRITE
Вернитесь к циклу выбора.
Когда срабатывает OP_WRITE, повторите запись. На этот раз, если он не вернет нуль, OP_WRITE и (возможно, согласно вашим требованиям) зарегистрируйте OP_READ.

Обратите внимание, что сохранение канала, зарегистрированного для OP_WRITE все время неверно. Канал сокета почти всегда доступен для записи, что означает, что в буфере отправки сокетов почти всегда есть место. Что вас интересует - это переход между незаписываемыми и доступными для записи.

Я увеличиваю прием и отправку буферов сокетов до 1 Мб в TcpTransportClient.intialize: socketChannel.socket (). SetReceiveBufferSize (size); socketChannel.socket () setSendBufferSize (размер). И добавьте этот код в sendMessage: rc = socketChannel.write (bytes); if (rc == 0) while (bytes.hasRemaining ()) {Thread.sleep (10l); rc = socketChannel.write (bytes); } Это нормально работает с сервером диаметра на c ++ на Debian, но на сервере jdiameter проблема не решена.
@MadCrank Увеличение размера буфера не ускоряет работу приемника, а только устраняет проблему. Вы не опубликовали свой исходный код, но ни while (bytes.hasRemaining()) while (rc < bytes.array().length) которые я нашел по вашей ссылке, являются правильным способом записи в NIO.
Нужно ли отменять регистрацию OP_READ?
@mike В этом нет необходимости, но нет смысла читать новые данные, если вы не можете записать старые данные. Пусть коллега остановится, вместо того, чтобы пытаться прочитать все новое, что он посылает вам, заполнить ваши собственные буферы чтения и т. Д.