Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


Don't forget to read Tuesday's email newsletter for your chance to win a free copy of Construct 2!


question about unconnected UDP sockets


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
5 replies to this topic

#1 lomateron   Members   -  Reputation: 363

Like
0Likes
Like

Posted 19 October 2013 - 05:17 AM

so that socket can receive data from everywhere

If I have a server with that socket and I am recieving data from different clients

Is it better in performance to create the same number of sockets to clients?

I mean as the server identifies that data has come from a new client it will create a new socket, and if data doens't comes from a client after 1 minute the server will delete a socket.


Edited by lomateron, 19 October 2013 - 05:29 AM.


Sponsor:

#2 Madhed   Crossbones+   -  Reputation: 3077

Like
0Likes
Like

Posted 19 October 2013 - 06:13 AM

I'm just taking a guess here: I think performace would not be the problem, It's possible however that lots of clients sending to the same socket can fill up the receive buffer if the server can not process datagrams fast enough. On the other hand, Opening more sockets would not solve that problem either. Maybe someone with more experience can answer.



#3 markr   Crossbones+   -  Reputation: 1653

Like
0Likes
Like

Posted 19 October 2013 - 07:57 AM

You should probably do the simplest thing which can possibly work and work on performance later.

 

Use a single socket. In practice it is generally easier to work with fewer sockets (i.e. just 1) rather than lots. You can easily multiplex many clients on a single socket by just processing packets as they arrive.

 

However, you should still consider using TCP as it solves a lot of problems for you and might be ok, depending on what kind of game you are making.



#4 samoth   Crossbones+   -  Reputation: 4926

Like
2Likes
Like

Posted 19 October 2013 - 10:13 AM

This is not so much a question about whether one or the other is more efficient, but about how things work.

 

If you are using UDP, then you will only have one socket (unless you plan to have every client use a different port, which would be kind of a weird design).

 

If you are using TCP, then you will have one listening socket, plus one socket per client that connects. It simply isn't possible to do something different.

 

Whether you use one or the other depends mainly on whether or not you can answer one question with "yes": "Do you need your data with as little delay as possible, and is it possible to ignore missing packets?" If the answer is "yes", you want UDP. If you are not sure or the answer is "no", stop thinking about UDP, you want TCP.

 

TCP works perfectly well and is not any "slower" than UDP. They perform exactly identical 99% of the time, but TCP is easier to use, as it emulates stream of data and is reliable, much as if you read from a file. The only time at which they differ (in their performance characteristics) is when packets are lost. TCP will wait for a short while and resend packets when no ACK comes in, and the other end will wait until the data has arrived in the correct order. Insofar, TCP works contrary to how IP (the protocol both TCP and UDP build on) works -- UDP on the other hand works exactly like IP. UDP will try to deliver each packet you send, but if it doesn't arrive, that's just bad luck for you. If you can live with this, it's perfect. If you can't live with that, you want TCP (it's possible to implement reliability on top of UDP too, but that's not trivial to do, and easy to get wrong, and it will not perform any better (though possibly worse) than TCP).


Edited by samoth, 19 October 2013 - 10:22 AM.


#5 rip-off   Moderators   -  Reputation: 8517

Like
0Likes
Like

Posted 19 October 2013 - 06:37 PM

The hard part about multiple sockets is how are you going to tell the clients which port to connect to? This is doubly hard when NAT is involved, where the port the server thinks it is using is not necessarily the same as the one the client thinks it is using. Real networks almost always involve NAT.

In addition, having multiple sockets doesn't buy you much, as you still have to handle random traffic arriving on the port that isn't from the "connected client". In fact, you may end up with even more spurious traffic as you're far more likely to collide with a known port if you have to generate new port numbers for each client.

The simplest solution with UDP actually turns out to have a single server port, and use the packet's IP address and port to lookup which client, if any, the packet should be associated with.

Edited by rip-off, 19 October 2013 - 06:37 PM.


#6 hplus0603   Moderators   -  Reputation: 5532

Like
0Likes
Like

Posted 20 October 2013 - 09:10 PM

Sockets are an OS-level concept, and are not visible on the network.

 

For most OS-es, for TCP sockets, there is one accepting socket, and each time a new client connects, the OS creates a new socket for you; writing to and reading from that socket will communicate with the client in question.

 

For UDP, you typically only use a single socket, as there is no "virtual circuit" or "connection" like in TCP. Instead, you can tell whether an incoming packet is from a known client by looking at the source address of the packets you receive, and you respond to the right client by using the sendto() function, specifying the address you got out of recvfrom().


enum Bool { True, False, FileNotFound };




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS