serious slowdown with ofxOsc on windows

hey all, I have an app which is sending a considerable amount of osc data per frame (250-500 floats = ~ 1-2KB) at 30fps. I’ve read that maximum UDP packet size is 65507 bytes (or can be 8192)?

Anyways, on osx I have no problems, everything is running super smooth under all conditions. On Windows (7 pro) I have problems. I’ve enabled options in my sender app to be able to send a small amount of data (a couple of bytes), or send the full amount of data (couple of KB). The problems below only happen on windows and only if I’m sending the full amount of data (if I’m sending small amounts of data everything runs smoothly).

  • if the target host goes offline, my sending app crawls to 1-2 fps.
  • Even if the target host is online, after a short while (could be a few minutes, could be a few hours) my sending app drops to about 5-10 fps.

on OSX, everything runs super smooth even under the above conditions.

This is probably an OS-level networking thing which is baffling me. Any suggestions welcome!

I discovered that oscpack opens the socket in blocking mode. So I had to download the source for oscpack, modify it and recompile.


	unsigned long mode = 1;  
	int ret = ::ioctlsocket(socket_, FIONBIO, &mode);	// MEMO, non blocking  

just after creating the socket in UdpSocket.cpp fixes it.


class UdpSocket::Implementation{  
    NetworkInitializer networkInitializer_;  
	bool isBound_;  
	bool isConnected_;  
	SOCKET socket_;  
	struct sockaddr_in connectedAddr_;  
	struct sockaddr_in sendToAddr_;  
		: isBound_( false )  
		, isConnected_( false )  
		, socket_( INVALID_SOCKET )  
		if( (socket_ = socket( AF_INET, SOCK_DGRAM, 0 )) == INVALID_SOCKET ){  
            throw std::runtime_error("unable to create udp socket\n");  
// add this:  
		unsigned long mode = 1;  
		int ret = ::ioctlsocket(socket_, FIONBIO, &mode);  
		memset( &sendToAddr_, 0, sizeof(sendToAddr_) );  
        sendToAddr_.sin_family = AF_INET;  

oscpack is great, but such a shame it doesn’t expose these options, similar to problems encountered on

also see

there are workarounds for each of these problems, but they really need to be integrated into oscpack…

Yea i saw these were incorporated into OF007, which is great. Just a shame they’re not optional in oscpack! This blocking vs non-blocking thing ended up being quite a killer for me! Try sending to a host which is no longer on the network, absolutely kills your machine if blocking is set to true! (which is default in oscpack).

well, couldn’t we integrate these things into oscpack? Kyle, you do have commit access to the repo, isn’t it?

i just looked into git svn, but it looks kind of annoying to set up. furthermore, my google account is in a weird indeterminate state right now that is not giving me write access to google code until i resolve some kind of ownership conflict.

maybe the best way to move forward quickly is just post a history-less copy of oscpack on github and start hacking?

yes, i was going to suggest that, let’s fork oscpack and add what we need, then we can ask Ross if he wants to merge it back later. It’s going to be the fastest

I just installed git-svn on linux (just an apt-get install away), and did a quick "git svn clone" and it seems I got all the history correctly, in a git repo. (I’m not really familiar with svn).
Should I upload that? Should we ask before publicly mirroring his repo (to be nice)? Committing back shouldn’t be a problem, just make a patch or diff file should be enough.

Edit: If I just clone the trunk, i.e. "git svn clone", I get the history starting with r52. Should be enough.

Edit2: Or maybe, a history-less version is better after all, to start with a clear, simple slate and not introduce errors and/or svn metadata.

historyless or not, i think sticking it on github and being prepared to merge patches from OF people will really push things forward fast. preserving history is better in my opinion, if possible.

we’re clearly fans of oscpack and want to help it survive, i’m sure ross will understand that we just need to collaborate in a different way before sending it back for a merge.

i think the main thing is just adding a note on the github readme that this is a development fork of the official repo, with a pointer to this thread + the github issue.

OK I just did that. Opened a new thread for coordinating the improvements:
Made a repo on github with partial history, and added arturo, kyle and memo as collaborators.