Почему Калифорния ждет после 65535 записей при отправке данных по протоколу CoAP

Я использую Калифорнийский API (https://github.com/eclipse/californium) для отправки данных с использованием протокола CoAP.

Ниже приведен фрагмент кода для клиента и сервера.

Сервер:

public class HelloWorldServer extends CoapServer {
    /*
     * Application entry point.
     */
    public static void main(String[] args) {
        try {
            // create server
            HelloWorldServer server = new HelloWorldServer();
            server.start();
        } catch (SocketException e) {
            System.err
                    .println("Failed to initialize server: " + e.getMessage());
        }
    }

    /*
     * Constructor for a new Hello-World server. Here, the resources of the
     * server are initialized.
     */
    public HelloWorldServer() throws SocketException {
        // provide an instance of a Hello-World resource
        add(new HelloWorldResource());
    }

    /*
     * Definition of the Hello-World Resource
     */
    class HelloWorldResource extends CoapResource {
        public HelloWorldResource() {
            // set resource identifier
            super("helloWorld");
            // set display name
            getAttributes().setTitle("Hello-World Resource");
        }

        @Override
        public void handleGET(CoapExchange exchange) {
            // respond to the request
            exchange.respond("Hello World!");
        }

        @Override
        public void handlePOST(CoapExchange exchange){
            //System.out.println("Start "+System.currentTimeMillis());
            exchange.accept();           
            //List<String> queries = exchange.getRequestOptions().getURIQueries();
        //    System.out.println("Text Received : "+ exchange.getRequestText().length());
        //    System.out.println("End "+System.currentTimeMillis());
            exchange.respond("Received");


        }
    }
}

Код клиента:

try {           

            long startTime = System.currentTimeMillis();
            for (int i = 0; i < 1000000; i++) {
                CoapClient client = new CoapClient(new URI("coap://192.168.15.170:5683/helloWorld"));
                CoapResponse response = client.post(str, 0);            

            }
            System.out.println("done");         
        } catch (URISyntaxException e) {
            e.printStackTrace();
        }catch (Exception e) {
            e.printStackTrace();
        }

Я отправляю 1000000 записей, но при отправке сначала он отправляет 65535 записей и ждет несколько секунд. После ожидания в течение нескольких секунд он снова начинает отправку.

Сведения о системе:

ОС: Win 7 64 бит. Оперативная память: 4 ГМ

Зачем ждать после 65535 записей?


person Vishvesh Phadnis    schedule 01.04.2015    source источник


Ответы (3)


Я прошел Калифорнию, CoAP получает 250 записей в секунду. Я добавил реле на 4 мс, чтобы ему удавалось отправлять менее 250 записей в секунду.

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

Идентификатор сообщения CoAP (MID) только с номера 1-65565.

Также правильно настройте Californium.properties, чтобы он работал.

person Vishvesh Phadnis    schedule 02.04.2015

В моем случае получение более 60 тысяч сообщений в минуту от одного клиента, уменьшение EXCHANGE_LIFETIME в californium.properties (или NetworkConfig, если хотите) было эффективным.

person einsys    schedule 06.08.2019

Просто упомяну:
16-битный CoAP идентификатор сообщения и время жизни обмена по умолчанию около 247 секунд,
в результате получается 250 msg / s. Следовательно, это ограничение по умолчанию - CoAP RFC7252.

Изменение этого EXCHANGE_LIFETIME на более низкое значение может привести к другим побочным эффектам.
Фактически, если сообщение (непреднамеренно) получено повторно после этого EXCHANGE_LIFETIME, это нарушает дедупликацию и / или передачу сообщения CON.

CoAP на самом деле не предназначен для потоковой передачи данных с одного power client. Поэтому мы сосредоточились на разработке в Калифорнии для поддержки сценариев использования, когда многие клиенты отправляют сообщения с умеренной скоростью, что приводит к высокой пропускной способности в этом случае.

person Achim Kraus    schedule 10.08.2019