Archived

This topic is now archived and is closed to further replies.

UDP Client's

This topic is 4934 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi to all, i was trying to run a UDP Server, and i found out what there is no accept function inside ! and i wonder how do i have to listen clients if i dont even know thair sockets? mfg wicked

Share this post


Link to post
Share on other sites
With UDP you usually don't have a single port per client, but rather one port for everyone. Like the op stated, you can get the address of the sender with recvfrom(), and you can send messages directed at a specific address from the same socket.



Looking for a serious game project?
www.xgameproject.com

[edited by - Max_Payne on April 21, 2004 7:55:54 PM]

Share this post


Link to post
Share on other sites
With UDP, you open up one port and let other people send data to you via that port. Clients connecting must know your ip and port to connect to. The same way you would connect to a Quake 2 server. Depending on whether or not you have blocking enabled, you would simply poll that port for incoming. If data is waiting to be read from that port, you will get it and the address of the client who sent it. Everything from that point is application/protocol specific.

Intro Engine

Share this post


Link to post
Share on other sites
my problem is that if i have 15 fast clients and 15 slow, then it may only recev messages from faster clients even if i recv messages 100 times every frame. i just dont know how to recv messages from all clients without waiting :|

edit: can this be that recvfrom() is blocking like accept `? ???

[edited by - Wickeeed on April 22, 2004 6:03:25 AM]

Share this post


Link to post
Share on other sites
By default (in winsock) sockets are created as blocking.

For non-blocking action either use ioctlsocket() to set the socket to non-blocking mode or better still use the WSAAsyncSelect/WSAEventSelect functions to activate asynchronous message/event notifications.


[edited by - arm on April 22, 2004 6:31:24 AM]

Share this post


Link to post
Share on other sites
quote:
Original post by arm
By default (in winsock) sockets are created as blocking.

For non-blocking action either use ioctlsocket() to set the socket to non-blocking mode or better still use the WSAAsyncSelect/WSAEventSelect functions to activate asynchronous message/event notifications.




how to use WSAAsyncSelect/WSAEventSelect ??? is that the same thing like select in TCP ?? can i use them if i only know client's ip's and nothin else.

is ioctlsocket() the best thing for UDP recvfrom()?
edit: or shul i make a thread for this?




[edited by - Wickeeed on April 22, 2004 6:44:31 AM]

Share this post


Link to post
Share on other sites
WSAAsyncSelect() tells winsock to message a window whenever a network event occurs. You can select the events that cause notifications.

WSAEventSelect() tells winsock to set an Event object whenever a network event occurs. Again, you can select the events that cause notifications.

ioctlcsocket() simply makes calls like recvfrom non-blocking so that if you call them and there is no data available, they will just return an error - you have to keep polling them until data is available.

Look at the documentation to learn more about the above functions. I cant tell you which one will fit best into your application.

Share this post


Link to post
Share on other sites
If i get it all right then that means that if i wuld use two TCP servers, one on blocking socket and one on non-blocking socket.. then the one that runs on non-b TCP will be like UDP and have the same speed ??? or it will be still slower ?

arm: i have searched a lot on google and still cant find a good tutorial or fag about these functions..

Share this post


Link to post
Share on other sites
The problems with TCP are that:

1) you need a socket per client
2) it will withhold data until all previous data has arrived

This isn''t changed when you go into non-blocking or asynchronous mode.

The manual claims that you can select() a UDP socket for reading just like a TCP socket.

Share this post


Link to post
Share on other sites
One thing you could maybe try, though I''m still working this out myself, is have the server create a new thread for each client connection. Whenever a message is recieved from a client, data is updated, and the server sends back the updated data.

The way my architecture is currently laid out, the server runs a recursive frame move method within a seperate thread. Whenever a client sends data (each frame move they send their updated state), the server updates it''s data, sends back a reply with it''s current data (say for all players) and goes back to happily running it''s recursive function. I have a large number of threads running with critical sections and mutexes all over hell''s half acre to keep everything in sync, but up to this point it seems to be working well.

This is a base look at it, but it should give you something to start with. If you want an in-depth look at designing network code for games, you may like to pick up a copy of Advanced 3D Game Programming with DirectX 9.0 by Peter Walsh. He has a whole chapter on the intricacies and issues of working with sockets and how to overcome them.

Permafried-

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
I have designed mine (UDP) to use a single thread to recv and a single thread to send, both for the server and client. The low level network stuff is wrapped up in a network class so that the user needn''t worry about critical sections/mutexs or local loop back if the app is both a server and client. The interface between the app and the network is done via priority queues using user supplied packets (destination, ACK, priority, msg, size). Similarly messages are recved via a priority queue.

SoulSpectre.

Share this post


Link to post
Share on other sites
hi everyone again, i have some questions...

that is my new architecture:
(everything in a single thread)(UDP)
1. recv info ->while(!done){ if(!my_recv()){ done } } <- store info
2. sort info
3. send it back to everyone

what you think about ???

new question.. how wuld you send a "shot" with tcp or udp ?? with tcp i wuld be slow and with udp it isnt right anyway... well i wonder how to do this stuff ..


thx for help everyone.. i hope you wuld help me this time

edit:

about creating a thread for every client... can someone post some code ? .. i wuld like to see, what it looks like

[edited by - Wickeeed on June 9, 2004 3:35:37 AM]

Share this post


Link to post
Share on other sites
please don''t create one thread per client. Kills scalability.

but just to actually answer the question you just create a thread and have the thread parameter be whatever information is needed to talk to the client. TCP this would be the socket for that client, UDP would be the address info structure.

however w/ UDP you have no idea who it is you are receiving from so you cannot have a thread that is the client state and read only from that client.

If you are going the thread route, use a work queue style implementation. read data, place in work queue, threads see theres work to be done, one gets the data nd works on it.

Share this post


Link to post
Share on other sites
OK, this seemed as good a place as any to pop a little question that''s been bugging me for some time - how well do NAT-enabled routers handle UDP? As far as I can see, the user would need to manually forward incoming packets on your game''s port to their gaming machine in order to play online, vs. a TCP stream that gets automagically handled. This wasn''t a problem when it was only geeks that had NAT devices sitting between them and the internet, but now a lot of people have routers sitting between them and teh intarweb.

Good cause for using TCP? (assuming that your game is aimed at a diverse audience, who won''t all be networking gurus).

Share this post


Link to post
Share on other sites
If the user first sends out a UDP packet to the server, and the server responds back to the address of the user that it sees as the sender of the packet, NAT will work perfectly for UDP.

In fact, with UDP, it''s possible to do NAT punch-through for peer-to-peer gaming; something you can''t do with TCP at all.

Share this post


Link to post
Share on other sites