Messages

1

Network / Re: Blocking problems.

« on: August 08, 2021, 05:24:16 am »

While tweaking with this I discovered, that sleep() between sending sockets might be helping. A side observation was, that sleep(0.1) actually does not work, since sleep is (at least in my case) only using integer values. So I successfully ended up in using usleep(50) which was enough time delay in microseconds, that made continuous sending sockets possible - at least I could indicate them without losing any in my homemade ESP32 receiver. And I can leave the socket blocking on as default.

Which changes the issue from "blocking problems" to "timing problems".

2

Network / Blocking problems.

« on: August 05, 2021, 04:34:50 am »

Introduction:
I have a Windows application Jinx! which continuously sends UDP sockets (ArtNet) with "usual" framerate so that the timing is critical.

I capture the sockets on ethernet with RaspberryPi4 running C with SFML library, make some treatment to the "picture" and send it further to the LED-matrix. So far I used the UART communication for sending to the panels. Now I have 6 panels with 512 LEDs each and the RPi4 has understandably problem feeding 6 UARTs with the baud rate of 1MB. So I want to change to ArtNet communication to the panels.
------------ end of introduction ---------------------

As long as I use the SFML for receiving the UDP sockets only (on low level) everything works fine. But when I introduced the socket.send() sending several sockets after a series of received ones, the routine is breaking the program - the receiving flow for considerable parts of a second which completely ruines the "video" flow. I tried with two different sockets (one for reception and one for sending). I also tried with socket.setBlocking(false) for the sending socket, which only resulted in sockets not being sent. I can not imagine the ethernet being unable to receive and send sockets in a continuous flow at the "same" time like on a server machine.
It looks like a sending socket is occasionally blocking the program for half of a second. Actually, it looks like several sockets are buffered in the hardware and sent later with an unwanted half a second break.

The program is basically receiving 64 ArtNet universes (UDP sockets) with the recommended

// UDP socket:
sf::IpAddress sender;
unsigned short port=6454;
if (socket.receive(data, 402, received, sender, port) != sf::Socket::Done)
{
    // error...
}

and then sending totally 24 ArtNet universes to three different IP receivers with:

// UDP socket:
sf::IpAddress recipient = "192.168.0.5";
unsigned short port = 6454;
if (socket.send(data, 402, recipient, port) != sf::Socket::Done)
{
    // error...
}

The documentation also mentions the  sf::SocketSelector class and blocking on a group of sockets, but that seems to concern receiving sockets and I can not see any use of it in sending scenario.

Any help is appreciated.