Difficulty Implementing External Service Message Transmission and Enabling Network Participants to Edit Messages in Artery

il3241ya commented 6 months ago

Hi!

I hope this message finds you well. I am currently working on a project where we need to implement the transmission of messages in the Artery using Protocol Buffers. The goal is to ensure that these messages can be propagated among network participants. While I've consulted the documentation, I couldn't find specific information on how to implement message transmission in Artery from a service external to SUMO.

I would greatly appreciate any assistance or guidance you can provide on addressing this issue. If there are any specific resources or examples available, it would be incredibly helpful.

Additionally, I have a question regarding granting each network participant the ability to edit these messages. Could you please provide insights or direct me to relevant documentation on this matter?

In view of a little context: our project does the integration of carla with opencda and artery. at the same time, opencda generates a message about its simulation in the form of a protobuf file, and then transmits it to an external resource. And at the moment, I need to teach this message to be accepted on the artery side and spread it on the network, edited in every hop. At the same time, the key fact is that we do not want to use sumo as an intermediate link for transfer to the artery

Thank you in advance for your time and support.

riebl commented 6 months ago

Hi @il3241ya,

you might be interested in the transfusion scenario which allows you to inject V2X data from outside and vice versa.

I am not sure if I have understood your question about editing messages, though. Any receiving entity can do whatever it wants with received data, so what limitation are you trying to solve?

SUMO has been the first and for quite some time the only mobility simulator supported by Artery. Today, we also have an implementation for OpenTrafficSim (OTS). So I am pretty confident that adding yet another simulator "moving vehicles around" is possible.

il3241ya commented 6 months ago

Thank you for your reply, @riebl!

Transfusion Service is an excellent suitable solution.

I connected it to my script, leaving the default remote_port=33080, however, when starting the artery, I get an error:

Transfusion Service: connect: Connection refused -- in module (artery::Transfusion Service) World.node[0].middleware.transfusion (id=86), at t=0.1s, event #2

As I understand it, this is due to the fact that the service does not see running processes on the socket localhost:33080. Therefore, I launched a "stub" on it listening to this port.

>> lsof -i :33080
COMMAND   PID        USER   FD   TYPE DEVICE SIZE/OF  NODE NAME
python3 13360    user      6u     IPv4  601047    0 t0  TCP    localhost:33080 (LISTEN)

riebl commented 6 months ago

As you have correctly stated, the TransfusionService tries to connect to an already listening TCP socket at 127.0.0.1:33080 by default. I have just verified with the socat utility that it is working:

run socat STDIO TCP-LISTEN:33080 in a terminal
start the "General" configuration of the transfusion scenario (run_transfusion) I then see data arriving on the terminal as expected and also my "garbage" typed in the terminal is received by the TransfusionService. Does this work on your system too?

il3241ya commented 6 months ago

Yes, it works with the Transfusion scenario (run_transfusion)

Maybe the problem is in the configuration files? I'll attach them below if it's helpful.

This is the content of the configuration files:

CMakeLists.txt

find_package(Protobuf REQUIRED)
protobuf_generate_cpp(PROTO_SRCS PROTO_HDRS TransfusionMsg.proto)

add_artery_feature(Transfusion
    TransfusionLoopback.cc
    TransfusionService.cc
    ${PROTO_SRCS} ${PROTO_HDRS})
target_include_directories(Transfusion PRIVATE ${PROTOBUF_INCLUDE_DIRS} ${CMAKE_CURRENT_BINARY_DIR})
target_link_libraries(Transfusion PRIVATE ${PROTOBUF_LIBRARIES})

add_opp_run(realistic_town06_cosim CONFIG omnetpp.ini)

omnetpp.ini

[General]
network = artery.inet.World
scheduler-class = artery::AsioScheduler

**.scalar-recording = false
**.vector-recording = false

*.traci.core.version = -1
*.traci.launcher.typename = "PosixLauncher"
*.traci.launcher.sumocfg = "realistic_town06_cosim.sumocfg"
*.traci.launcher.sumo = "sumo-gui"
*.traci.launcher.port = 8813

*.node[*].wlan[*].typename = "VanetNic"
*.node[*].wlan[*].radio.channelNumber = 180
*.node[*].wlan[*].radio.carrierFrequency = 5.9 GHz
*.node[*].wlan[*].radio.transmitter.power = 200 mW

*.node[*].middleware.updateInterval = 0.1s
*.node[*].middleware.datetime = "2013-06-01 12:35:00"
*.node[*].middleware.services = xmldoc("services.xml")
*.node[1].middleware.transfusion.remote_port = 33080

[Config loopback]
network = LoopbackWorld
*.loopback.port = 8000

services.xml

<?xml version="1.0" encoding="UTF-8"?>
<services>
    <service type="artery.application.CaService">
        <listener port="2001" />
    </service>
    <service type="artery.transfusion.TransfusionService" name="transfusion">
    </service>
</services>

LoopbackWorld.ned

import artery.transfusion.TransfusionLoopback;

network LoopbackWorld extends artery.inet.World
{
    submodules:
        loopback: TransfusionLoopback {}
}

And my scenario folder structure

realistic_town06_cosim/
├── CMakeLists.txt
├── General.anf
├── LoopbackWorld.ned
├── omnetpp.ini
├── realistic_town06_cosim.net.xml
├── realistic_town06_cosim.net.xml.save
├── realistic_town06_cosim.poly.xml
├── realistic_town06_cosim.rou.xml
├── realistic_town06_cosim.sumocfg
├── results
│   ├── General-#0.sca
│   ├── General-#0.vci
│   └── sumo-0.log
├── sensors.xml
├── services.xml
├── store
│   └── store.txt
├── TransfusionLoopback.cc
├── TransfusionLoopback.h
├── TransfusionLoopback.ned
├── TransfusionMsgArchive.proto
├── TransfusionMsg.proto
├── TransfusionService.cc
├── TransfusionService.h
└── TransfusionService.ned

riebl commented 6 months ago

I don't think that Artery is misconfigured but that the external application is not listening properly. Maybe it is opening the listening socket too late, i.e. after TransfusionService tries to connect?

il3241ya commented 6 months ago

Thank you very much for the answers! I found the right solution for our project, without using the transfusion service

riebl / artery

Difficulty Implementing External Service Message Transmission and Enabling Network Participants to Edit Messages in Artery #327