[SOLVED] Network - Cumulative delays on receiving data


#1

Hi!

Forum newbie here. Not usually an asker, but I faced a communication problem I do not know even where to start to search for a “fix” (perhaps due to lack of theory).

I have a mocap system outputting TCP or UDP that I wanted to pass into OF (I’ve used the data with vvvv, unity and unreal before, so I know how it’s sent).

I managed to grab some of it (ofxTCPClient.receive + custom delimiter; .receiveRaw + rebuilding the stream; ofxUDPManager.Receive…). BUT, – and here is where my ignorance blocks me – no matter the method, after some seconds of exchange, it behaves as if it’s accumulating a stack of received data, and a delay builds up. To the point that you might pause the sending of data, but the OF app keeps on reading them (old ones) for a while.

Some years ago I did networking with C++ and Asio, but never needed to worry about proper instructions. But now I don’t know how (or what to study) to properly build up a sturdy system within OF for always providing the most recent message received.

I’m already blindly testing stuff, like changing framerates or even calling .receive multiple times, in an attempt to “dump” excessive data. Apart from happy accidents, this is really going nowhere. Even if I generate my own TCP stream from somewhere else, like vvvv, I also got to these delay build-up scenario.

Any insight will be greatly appreciated! Many thanks and hurray for such a lovely community!


#2

it would help to see some code but you are probably only receiving one message per frame while sending much faster than that. use a while loop until there’s no more messages to receive everything available everyframe


#3

Thank you sir! Sounds simple enough.
I’ll update this thread as soon as I properly implement it.
(about code, this “problem” happened also with the TCP network example, just changing the delimiter)


#4

So, after a bunch of testing, I noticed the while loop concept could be useful when there’s a ton of tiny messages being sent. But, on that case, I never got any delay even without the loop.

So the problem appears when the message is long. The one the software sends is around 2000 characters. When receiving that, the ofApp even has some frames where the receive function doesn’t grab anything.
So I tested it from ofApp to ofApp, sending a long message. Starting with the TCP examples from network addon, if I have a sender like this:

// Sending a timer + lorem ipsum message
void ofApp::update(){
	if (doSend)
	{
		TCP.send(0, ofToString(ofGetElapsedTimeMillis()) + " Lorem ipsum dolor sit amet, consectetur adipiscing elit. Donec placerat consequat pretium. Cras venenatis ligula vel eros semper, vel eleifend lacus imperdiet. Sed eget orci fermentum magna finibus malesuada sed luctus magna. Nulla dui nisl, molestie non dolor id, malesuada lobortis erat. Morbi ligula turpis, interdum et magna nec, laoreet maximus metus. Phasellus sodales nec leo a lacinia. Sed tortor dui, congue sed volutpat id, bibendum gravida enim. Duis velit dolor, lobortis sed ultricies pulvinar, condimentum nec massa. Nunc et imperdiet orci. Ut faucibus mauris felis, id vulputate quam suscipit id. Morbi id tortor augue. Vestibulum lectus libero, lacinia sed laoreet sit amet, malesuada in est. Nullam risus sem, viverra id pellentesque id, vulputate id turpis. Nunc vestibulum tincidunt tellus vel hendrerit. Duis ultrices pellentesque congue. Nulla euismod fringilla magna, dictum blandit libero lobortis non. Donec ac eleifend neque, quis blandit nisi. Pellentesque viverra nulla nec est placerat, in dapibus purus tincidunt. In accumsan sapien non feugiat bibendum. Sed ultricies eget magna non molestie. Aenean sit amet scelerisque sem. Sed a ante sem. Maecenas porttitor leo nec tellus consectetur dapibus. Quisque egestas elementum ex vel consectetur. Aenean facilisis, quam vitae rutrum consectetur, lectus neque vulputate sapien, sed molestie odio est nec diam. Suspendisse imperdiet volutpat massa, at malesuada ex gravida nec. Sed sed libero massa. Nulla maximus ac lacus sit amet accumsan. Nam dapibus metus id faucibus congue. Donec eros lacus, scelerisque sit amet consequat eu, gravida et diam. Suspendisse eleifend, risus sed iaculis sollicitudin, dui metus tempor elit, id mollis nunc tortor nec est. Duis venenatis massa eget ultrices tristique. Donec urna lectus, vulputate eu ornare vitae, fringilla eu erat. Integer bibendum leo eget orci ultricies, semper egestas nibh iaculis. Nunc non nisi ullamcorper, dictum orci quis, convallis ante. Cras maximus tempor nullam.");
	}
}
void ofApp::keyPressed(int key){
	if (key == 's')
		doSend = !doSend;
}

…and a receiver like:

void ofApp::update() {
	if (tcpClient.isConnected()) {
		string str = tcpClient.receive();
		if (str.length() > 0) 
			msgRx = str; 		// message to be printed on screen
	}
}

…already when I toggle the sending on, and then off, the receiver will still show this delayed behavior.

I feel I’m stumbling on some silly lack of knowledge about what’s happening under the hood, but I’d be grateful for any advice on it!


#5

can you try?

char byte;
while(tcpClient.peekReceiveRawBytes(&byte, 1)){
    string message = tcpClient.receive();
    if(message != ""){
         msgRx = message;
    }
}

#6

Yup. It was looping forever, as I found out it returns -1 for no message. Using something like:

while(tcpClient.peekReceiveRawBytes(&byte, 1)>0)

works like a charm!

Thank you!