Forum

You must be logged in to post Login


Lost Your Password?

Search Forums:


 






Wildcard Usage:
*    matches any number of characters
%    matches exactly one character

UDP port reuse

No Tags
UserPost

11:49 am
January 29, 2011


Paul

Admin

posts 49

Hi Bryan,

You're welcome to change the library in any way you wish. But, I'm having trouble understanding what about the library doesn't support what you're doing. Specifically, the OscServer class, either via TCP or UDP, supports incoming data from any number of simultaneous transmission sources. So, if I follow your application design, you have six computers each supporting different input types, and their inputs are all transmitted to a single receiver station (what one would perhaps dub the "server" and which might host a common representation of the game world).

If I understand your design correctly, then this will work without requiring modification of the library. You'll host a single OscServer object on the common station, listening for UDP packets on a single port, and accepting OSC packets from any-or-all of the 6 client stations simultaneously. Certainly, each input device will send different data, and this is where the bulk of your true effort comes to play. That is, the design of the specific data that each client will transmit. You can identify the different "client protocols" by designating a different OSC address for each. For example:

/game-input/joystick

/game-input/trackball

If I'm misunderstanding your application, please clarify and I'll do my best to advise.

As an aside, I noticed your email address is from CMU's ETC program. I teach at the Florida Interactive Entertainment Academy and have a colleague from the ETC. Are you a student or a professor?

 

Paul

 

Posted from Bryan on the OSC comments section:

Paul,

very nice library. I’m wondering if you could provide some insight to a problem I’m trying to solve. I am building a custom gaming interface with buttons, trackballs, joysticks, and touch surfaces. The entire installation is comprised of six user stations. I would like to unify all hardware and software communication using OSC. The problem is that I can not open more than one OscServer (receiver) on the same port despite the fact that I’m binding to “ANY” and sending my messages as “BROADCAST”. UDP sockets on Windows allow port reuse and non-exclusive binding but must be explicitly opened using the SO_REUSEADDR attribute. What are your thoughts on modifying the Bespoke OSC library to do this? Will I break anything?

Thanks.

3:14 pm
February 1, 2011


Bryan

Guest

Paul,

I am a programmer on staff at the ETC.  They refer to me as one of their CS department refugees;-)

The nature of the problem has to due with programs on the same machine using the same port to communicate with each other.  The game environment we are building represents the bridge of a space ship with six crew stations.  Each station is controlled by it's own CPU and has two monitors in an over-under configuration, the lower screen is a multi-touch surface surrounded by traditional game input devices.

A station has many applications running it which perform different functions: CCV + TUIO for multitouch; Panda3D, GameMaker, and Flash for game content; and a C# program which allows the upper monitors to function as a videowall.

All applications must be able to receive input from the game controllers as well as from each other.  In our initial prototype we used a number of adhoc techniques such as SendKeys, shared files, and sockets for IPC. We are hoping to use OSC as a unifying communications protocol.  We could, of course, use different port numbers for each application, but after a while that seems to become an n-to-n problem where a new program comes along and all the other ones have to be updated to listen to it's port, et cetera.  The obvious approach, since OSC provides an addressing mechanism as you point out, is to have everyone send and receive on the same port or ports and simply choose which message addresses to listen to.

What are your thoughts?

9:50 pm
February 1, 2011


Paul

Admin

posts 49

Hi Bryan,

CS department refugee… I like it. Thanks for the detailed explanation, I've got what you're going for now. So, I did a little digging, and this is definitely possible. If you've looked into my code at all, you may have noticed the underlying UdpClient class that is at the heart of the UdpServer. None of the 5 UdpClient overloads allows port reuse, so you need to build and bind the Socket separately, and then associate an "empty" UdpClient object with this socket.

In particular, the principal change is within the Start() methods of the UdpServer class — specifically for the multi-cast option. You instantiate a Socket object, and call it's SetSocketOption() method with some specific arguments for enabling port Reuse. Finally, you assign the UdpServer's mUdpClient.Client property to this newly created socket.

Note, that port reuse only functions for UDP multi-cast, not unicast (and I haven't experimented with broadcast). Thus, you have to specify the transmission type as multi-cast when instantiating the OscServer object, and your server address must be a valid multi-cast IP address.

I've written and tested this, and have uploaded an unofficial 1.6 version of the Bespoke OSC Library to http://www.bespokesoftware.org…..rk_1.6.zip.

This updated version includes a demo that employees multi-cast, and hence you can startup multiple "Client" instances (which, though the naming is odd, is the application that instantiates an OscServer object and listens for OSC packets).

Please note that I haven't included Visual Basic versions of the demo, and I'm hesitant to officially publish this release until I've tested it a bit more… but, it seems to work as expected. You can fire up multiple OSC receivers on the same computer, binding to the same port, and each of them will receive any OSC packets sent to that port (with the normal UDP-isn't-guaranteed-delivery caveats).

I've even included pre-compiled binaries of the library and demo, so you can very rapidly fire up multiple clients and servers to test the behavior.

Let me know if you have trouble.

Paul

1:36 pm
February 4, 2011


Bryan

Guest

Paul,

thanks for the code, this is awesome.  I'll let you know how things turn out.

-Bryan

 

No Tags

About the Bespoke Software forum



No Comment

Comments are closed.