Broadcast packets using UDP
by K. Anderson · in Torque Game Engine · 02/20/2008 (9:27 pm) · 10 replies
I need to broadcast a structured UDP packet on a specified port containing information from the engine. The packet needs to contain a combination of float and int values and transmit at about 60 times a second. I have an exe(not another torque instance) that needs to pick up the information but I've been unable to get anything out to it from the engine so far. I've looked around a bit and all that I've been able to come up with is incoming over the TGE protocol layer but no broadcasting. I thought that these two would be the answer but still no luck.
Net::openPort() opens an unreliable socket, of which only one is allowed per application instance. Net::sendto() sends an unreliable datagram to the specified NetAddress.
Essentially I point the exe to the game address and port and it looks for packets coming out with UDP. So far I've been unable to get anything out that the exe can detect. If anybody has dealt with this before I would love to hear your solution.
Net::openPort() opens an unreliable socket, of which only one is allowed per application instance. Net::sendto() sends an unreliable datagram to the specified NetAddress.
Essentially I point the exe to the game address and port and it looks for packets coming out with UDP. So far I've been unable to get anything out that the exe can detect. If anybody has dealt with this before I would love to hear your solution.
#2
"UDP via LAN, via a buffer containing a C structure. Data should be updated at between 50 and 200hz."
Am I misunderstanding how I should be communcating to the software? I had assumed the buffed it was talking about was the exe. Could it mean that the buffer needs to be something simulating a client that then passes the packets onto the exe?
EDIT: The exe will be running on the same machine as the torque instance.
02/20/2008 (9:54 pm)
Normally the exe listens to a simulation, you enter the address and the port that it uses, here is the description of the game > exe communication:"UDP via LAN, via a buffer containing a C structure. Data should be updated at between 50 and 200hz."
Am I misunderstanding how I should be communcating to the software? I had assumed the buffed it was talking about was the exe. Could it mean that the buffer needs to be something simulating a client that then passes the packets onto the exe?
EDIT: The exe will be running on the same machine as the torque instance.
#3
If you don't have a client that can at least emulate the connection handshake the server expects, you'll never get any UDP from it.
I'm not sure where
is from.
If you just want Torque to start sending UDP to a given port, you'll probably have to use Net::sendTo, along with code layered on top, to send what you need from Torque. Net::openPort opens the UDP listener port, which you really only ever need one of.
If you have a piece of software you have configured to listen to port 28000, UDP, you're not going to see anything. Torque only sends simulation packets to clients.
02/21/2008 (10:29 am)
Well, the server controls who is in the client list. It only sends UDP to clients that are actually connected and running/playing.If you don't have a client that can at least emulate the connection handshake the server expects, you'll never get any UDP from it.
I'm not sure where
Quote:
Normally the exe listens to a simulation, you enter the address and the port that it uses, here is the description of the game > exe communication:
"UDP via LAN, via a buffer containing a C structure. Data should be updated at between 50 and 200hz."
is from.
If you just want Torque to start sending UDP to a given port, you'll probably have to use Net::sendTo, along with code layered on top, to send what you need from Torque. Net::openPort opens the UDP listener port, which you really only ever need one of.
If you have a piece of software you have configured to listen to port 28000, UDP, you're not going to see anything. Torque only sends simulation packets to clients.
#4
Is it that UDP can't be broadcast or just that Torque doesn't do it? It's been a while since I did any network coding so I'll start digging around on here to see if anything similar was done in the past.
Thanks for your help so far.
02/21/2008 (1:59 pm)
Sounds like I'd either need to modify the exe to pretend to be a client or build some special network functions to handle it.Is it that UDP can't be broadcast or just that Torque doesn't do it? It's been a while since I did any network coding so I'll start digging around on here to see if anything similar was done in the past.
Thanks for your help so far.
#5
02/22/2008 (3:11 am)
Using a packet sniffer, the queries to the master server are picked up. What I'm looking at trying to do is snag the functions for the master server and rebuild a modified version of them to send out physics information to a local ip instead of their normal checks to the master server. If I can figure out how to pull out the stuff for the handshake I'm thinking that I can pick up the info I need on the exe by using this without needing to go through a handshake process and fake a client. Then its just a matter of throwing it into the client side physics processing to get the hz needed. Thoughts?
#6
So, can anybody throw out the "oh duh" way to do this that I'm just completely missing? Thanks.
02/23/2008 (8:28 pm)
Allright, I ditched the master server idea and went ahead and threw in a simple udp function to send out a packet, right now that's just saying "hello" and I'm picking it up fine with the exe. The problem I've got right now is that I can't figure out how to fill up the buffer with the datagram. Once I get that worked out I can set it up to fill up with vehicle physics data and I'll either call it through script like i'm doing now or have it called in the physics calc for the vehicle itself. I'm looking at doing 60-100hz if anybody knows how fast the physics ticks?So, can anybody throw out the "oh duh" way to do this that I'm just completely missing? Thanks.
#7
So, can anybody throw out the "oh duh" way to do this that I'm just completely missing? Thanks.
02/23/2008 (8:46 pm)
Allright, I ditched the master server idea and went ahead and threw in a simple udp function to send out a packet, right now that's just saying "hello" and I'm picking it up fine with the exe. The problem I've got right now is that I can't figure out how to fill up the buffer with the datagram. Once I get that worked out I can set it up to fill up with vehicle physics data and I'll either call it through script like i'm doing now or have it called in the physics calc for the vehicle itself. I'm looking at doing 60-100hz if anybody knows how fast the physics ticks?So, can anybody throw out the "oh duh" way to do this that I'm just completely missing? Thanks.
#8
E-mail me at mperry@zombieshortbus.com
02/23/2008 (9:16 pm)
K. Anderson. Not sure when your deadline is, but send me an e-mail tonight or tomorrow. I have your solution, which is quite simple. I've already have coded and tested this (did so about a year ago).E-mail me at mperry@zombieshortbus.com
#9
02/23/2008 (9:33 pm)
Email sent, that would be great to get this part out of the way.
#10
http://www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=12517
That has worked but I'm running the updates at 100hz through a script schedule and I'm getting lag and pretty high CPU usage. I'm not sure if that's because I'm running through the script side or not. 50ms/20hz schedules run just fine but that's not a fast enough update. Any advice on using schedules in the c++ side rather than script side?
Other than that its time to try hunting for xyz velocities and accellerations.
EDIT: For anybody who is looking to broadcast UDP datagrams, right now I'm using the winsock sendTo() command and passing in the datagram as the message with (char*)&dGram
02/24/2008 (3:48 pm)
Now that the datagrams are getting sent across and read properly I've been spending the day trying to fill in the correct physics info. I've found a couple different resources and I've implemented and testing out the resource to retrieve the pitch, roll and yaw found here:http://www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=12517
That has worked but I'm running the updates at 100hz through a script schedule and I'm getting lag and pretty high CPU usage. I'm not sure if that's because I'm running through the script side or not. 50ms/20hz schedules run just fine but that's not a fast enough update. Any advice on using schedules in the c++ side rather than script side?
Other than that its time to try hunting for xyz velocities and accellerations.
EDIT: For anybody who is looking to broadcast UDP datagrams, right now I'm using the winsock sendTo() command and passing in the datagram as the message with (char*)&dGram
Tim McClarren
Default Studio Name
If you want a Torque server to send UDP to your non-client executable, you'll have to at least emulate the connection handshake that happens between a normal client and server.