Connecting & Reading to a TCP/IP socket from a different ROS Node

asked 2021-01-15 05:17:27 -0500

Radeshwar gravatar image

Hi Friends,

I am using TCP/IP protocol for one of my application, in which I am creating a TCP/IP socket to Transmit/Receive data from/to the Server (a different PC).

My system is the Client in which I have created two ROS nodes (say A & B),

1) Node A(Command Data) - to create the socket (including creating a socket, assigning IP & Port no and establishing connection) and to transmit the data(TCP Packets).

sockfd = socket(AF_INET, SOCK_STREAM, 0); 
if (sockfd == -1) 
{ 
    cout<<"\n socket creation failed...\n";
    exit(0); 
} 
else
{
    cout<<"\n Socket successfully created..\n";
}

bzero(&servaddr, sizeof(servaddr));
Sock_sts_flag = SET;

servaddr.sin_family = AF_INET; 
servaddr.sin_addr.s_addr = inet_addr(IP_ADDRESS);
servaddr.sin_port = htons(PORT_LCU);

if (connect(sockfd, (SA*)&servaddr, sizeof(servaddr)) != 0)
{
    cout<<"\n Connection with the server failed...\n";
    exit(0); 
} 
else
{
        cout<<"\n Connected to the server...\n";
}

2) Node B(Feedback) - to read the data from the same socket.

n = read(sockfd, buff_lcu, MAX_ARRAY_SIZE_FB);

cout<<"\n n = " <<n;

if(n < 0)
{
    cout<<"\n Couldn't Read from Socket";
}
else
{
      // Perform task
}

I am able to achieve the first part of the problem, which is creating a TCP/IP socket and establish the connection between the Client & Server and transmit data from the Client. I have even validated the received packets on the server side and its fine.

My Server is also sending the feedback data in the same socket once the connection is established but I am not able to read that data if I launch my Node B.

I verified the packets sent by my Server using

$ sudo tcpdump -XX -i enp1os

and I am receiving the expected packets.

When ever I launch my Node B it come and stops at the read() and doesn't proceed even though it is in a While loop.

I even tried sending the sockfd via a ROS service from Node A (Service - Client) to Node B (Service - Server) and receiving the actual value of the sockfd but still not able to read the data via Node B.

Kindly suggest a solution for this.

Thanks

edit retag flag offensive close merge delete

Comments

I implemented similair functionality by creating a tcp_client_node' it subscribes to /tcp_to_send and publishes on /tcp_received. now you can just use the ROS topics from any node to send or read TCP/IP messages. (not an answer to your question but might be a possible solution for your problem)

crnewton gravatar image crnewton  ( 2021-01-15 05:30:44 -0500 )edit

@crnewton : I am trying to avoid ROS Topics in this case that's the reason I am going with two different nodes instead of one. My worst case scenario would be to go with ROS Topics but I am trying to explore other options too.

I still appreciate your response.

Radeshwar gravatar image Radeshwar  ( 2021-01-15 05:40:04 -0500 )edit

Are you trying to "share" a socket (the same socket) between two different processes?

That's typically not supported, regardless of whether ROS is involved.

gvdhoorn gravatar image gvdhoorn  ( 2021-01-15 09:45:53 -0500 )edit

typically yes, I have 2 nodes and both are trying to access the same socket.

Radeshwar gravatar image Radeshwar  ( 2021-01-18 04:21:36 -0500 )edit

"typically"? I don't understand what you mean by that.

Two processes trying to bind(..) or accept(..) the same port is not supported afaik.

This is not ROS specific (or influenced by anything in ROS), but your OS.

gvdhoorn gravatar image gvdhoorn  ( 2021-01-18 04:25:26 -0500 )edit

It is possible to create a socket using one node and pass on the file descriptor to the other node? Will that help?

Radeshwar gravatar image Radeshwar  ( 2021-01-18 04:43:34 -0500 )edit

Well it's software, so anything is possible. But it certainly wouldn't be standard usage of sockets.

Sharing resources between different processes is not trivial.

It's also not ROS-specific, so I believe it would be better to either post your question on a more suitable forum, or rethink your approach and don't try to work-around a fundamental OS limitation.

gvdhoorn gravatar image gvdhoorn  ( 2021-01-18 04:49:30 -0500 )edit

@gvdhoorn Thank you so much and I appreciate your rapid response.

Radeshwar gravatar image Radeshwar  ( 2021-01-18 04:59:00 -0500 )edit