Original Post
🔒 Locked
UDP help
Advertisement
Feasible? Both.
quote:
Original post by Robinhood
How do I know the remote IP when I use receiveFrom in Server
Pass an address struct in, and it will contain the address after you call the function.
--
You''re Welcome,
Rick Wong
- Google | Google for GameDev.net | GameDev.net''s DirectX FAQ. (not as cool as the Graphics and Theory FAQ)
> Can you explain the detail?
Nothing magic here. Ports are OS abstractions and more of them opened won''t make your network card go any faster. Having one port per user allows you to have a separate buffer, but then having 000s of them eats up memory that needs to get pinned down in physical RAM. You''re better off with a single port and perform a client lookup based on the incoming IP & port.
If you plan on a Windows NT/2K/XP -only solution, then you should investigate IOCP. Here is some source code you can sink your teeth into: http://pages.infinit.net/cbenoi1/iocp_udp.zip
-cb
Nothing magic here. Ports are OS abstractions and more of them opened won''t make your network card go any faster. Having one port per user allows you to have a separate buffer, but then having 000s of them eats up memory that needs to get pinned down in physical RAM. You''re better off with a single port and perform a client lookup based on the incoming IP & port.
If you plan on a Windows NT/2K/XP -only solution, then you should investigate IOCP. Here is some source code you can sink your teeth into: http://pages.infinit.net/cbenoi1/iocp_udp.zip
-cb
Having one port should work - provided you can read the packets fast enough. If you can''t, then nothing would really work anyway.
On approach is to create a STL map which maps IP addresses (or for completeness, IP address, port number pairs) on to some kind of object which you store the connection info in.
The connection info would be dynamically stored in a struct or object, when each packet arrives you can do a key lookup on the map to find out which client it was from.
Because of course, packet spoofing could be used to DoS, you could create some kind of connection key which would be added to the packet somewhere, and check it matches.
Then the only tricky bit is, somewhere in your main loop you have to periodically check for clients which have gone dead, and disconnect them (thus freeing resources).
One approach I''ve used in a (non-game) project, is to keep a priority queue, and queue tasks on to it based on the time they next need attention (for example, some processing or a disconnect timeout). Then just look at the head of the priority queue, work out how long to sleep for and wait for that long.
Mark
On approach is to create a STL map which maps IP addresses (or for completeness, IP address, port number pairs) on to some kind of object which you store the connection info in.
The connection info would be dynamically stored in a struct or object, when each packet arrives you can do a key lookup on the map to find out which client it was from.
Because of course, packet spoofing could be used to DoS, you could create some kind of connection key which would be added to the packet somewhere, and check it matches.
Then the only tricky bit is, somewhere in your main loop you have to periodically check for clients which have gone dead, and disconnect them (thus freeing resources).
One approach I''ve used in a (non-game) project, is to keep a priority queue, and queue tasks on to it based on the time they next need attention (for example, some processing or a disconnect timeout). Then just look at the head of the priority queue, work out how long to sleep for and wait for that long.
Mark
When you call recvfrom, the IP address in the struct sockaddr_in will be the address of the client.
That''s all the server needs to know. The server does not need to know its own IP address - and with good reason - NAT and/or multihomed hosts may make it impossible in the general case for a server to have exactly one IP address.
You should receive the real IP / port number of the clients from recvfrom, if it''s a "Virtual" IP whatever that is (probably a reserved IP?), then the clients'' IP addresses must have been NAT''d by your firewall.
But in any case, you don''t care what they are, just send the responses back to the same IP / port that the requests came from, and it should be fine.
Mark
That''s all the server needs to know. The server does not need to know its own IP address - and with good reason - NAT and/or multihomed hosts may make it impossible in the general case for a server to have exactly one IP address.
You should receive the real IP / port number of the clients from recvfrom, if it''s a "Virtual" IP whatever that is (probably a reserved IP?), then the clients'' IP addresses must have been NAT''d by your firewall.
But in any case, you don''t care what they are, just send the responses back to the same IP / port that the requests came from, and it should be fine.
Mark
If you''re behind a router with your own IP addresses, then there''s nothing the outside world can to to choose to contact individual computers on your network directly. All you can really do is set up port forwarding on the router that will map inbound requests on given ports to designated machines.
[ MSVC Fixes | STL Docs | SDL | Game AI | Sockets | C++ Faq Lite | Boost
Asking Questions | Organising code files | My stuff | Tiny XML | STLPort]
[ MSVC Fixes | STL Docs | SDL | Game AI | Sockets | C++ Faq Lite | Boost
Asking Questions | Organising code files | My stuff | Tiny XML | STLPort]
Topic Locked
This topic has been locked by a moderator. New replies are not allowed.
Sign in to reply to this topic.
Advertisement