asynchronous interface bug when send burst of SOME/IP Message requests

[yunfeiyangcc]

trafficstars

@lutzbichler

If you send 100000 request message(MT_REQUEST) using an asynchronous interface. The application thread not working so the clients_ can not be consumed, Because the CPU is occupied by endpoint to receive data (udp_server_endpoint_impl::on_message_received). the session id will exceed 0xFFFF and the data of clients_ will be overwritten.

After the session id exceed 0xFFFF, the server can not reply to the client with response.

So should it use std::deque to store the session?

server_endpoint_impl.hpp:

change
// std::map<client_t, std::map<session_t, endpoint_type> > clients_;
to
std::map<client_t, std::deque<std::pair<session_t, endpoint_type>>> clients_;

Similarly, in capicxx-someip-Runtime Connection.hpp:

[lutzbichler]

I do not understand the term "asynchronous interface". Could you provide an example (code) of your problem?

[yunfeiyangcc]

I implemented a micro program, similar to vsomeip by myself, it can send data to vsomeip.

In my tests, two programs, one server and one client, the server is in a virtual machine(Ubuntu), the client is in another.

The function of the client is to send a request, and the function of the server is to feedback a response to the client.

The server is implemented using vsomeip and "hello_world_service"， but I modify the code so that it only send a response.

The client is implemented using my micro program, it only send a request.

The synchronization interface means that the client sends a request, the server sends a response, and the client must wait until the response before sending a second request.

The asynchronous interface means that a client can send multiple requests at once without waiting for a response, the asynchronous interface Similar to sendMessageWithReplyAsync in capicxx-someip-runtime (https://github.com/GENIVI/capicxx-someip-runtime).

So I used the async interface of the client to send 100,000 requests. If the server can't process them in time, the session id will exceed 0xFFFF. this is question 1. eg:

    for (int i = 0; i < 100000; ++i)
    {
        mMethod->EchoInt64Async(i + 1, /*callback*/);  // send 100000 requests, 1 ... 100000
    }

In my micro program, I just used a socket endpoint to send data to the server.

The question 2: The server may lose data because the client sends data too quickly. in udp_server_endpoint_impl.cpp: unicast_socket_: No 50000 requests were received. but the client(my micro program) did send 5000 requests as shown in the wireshark. In this case the session id did not exceed 0xFFFF, but the data was lost. I guess it's the bug of Boost endpoint. What do you suggest?

The server log:

[yunfeiyangcc]

For question 2: Because in my micro program it looks something like this: for (int i = 0; i < 5000; ++i) { sendto(fd, data, size, ...); // send udp datagram to vsomeip. }

Data is sent too fast, causing UDP packet loss.

I changed the socket receive buffer in /etc/sysctl.conf using the following command:

sudo vi /etc/sysctl.conf
net.core.rmem_default=262144
net.core.rmem_max=4194304
sudo sysctl -p

It can work good. What do you think about that? Is this considered in vsomeip?

[ByteXiaoTang]

i think the business module should care the life time of service and try to use timer to cover the condition.

[kheaactua]

hey @yunfeiyangcc about your micro-program, could I see the source? I'm also setting up tests for vsomeip and this might be helpful. I've been using vsomeip_ctrl, but I'd prefer something that doesn't use libvsomeip

[fcmonteiro]

Please retest with latest sw version