TCP/IP Ports
Author
How many connections can you have through a single TCP/IP port? Does the port have a bandwidth.
I''m using the WinSock API at the moment but I''m not sure about this problem. Do I assign each user a new TCP/IP Port or do I bundle them all through one port?
im newb at networking so dont take this as certain, but you probably could put all users/players thru one port I think this is what most games do now. Ports do not have a bandwidth only the connection. You may however want to have a different port for joining to prevent DOS attacks (I dont know if this will work but i remember reading something about using UDP to prevent DOS attacks) Ports simply accept packets of data. The source information is encoded in the header so you can simply find out where its from using the source ip. I know hardly anything about Winsock so dont ask me 
. Someone else can tell u about that. I hope this helps (and is not complete crap).
. Someone else can tell u about that. I hope this helps (and is not complete crap).
An IP port is essentially one connection. What happens when you accept an external connection, is that it moves that connection onto a new port, freeing up your listening port again. Generally you don''t need to worry about what port you''re using for accepted connections as the OS picks a random unused one for you. You just keep 1 port open as a listening socket (assuming you''re running a ''server'') and the API calls do the rest (until you want to do complex stuff).
Author
that''s sort of like what I''m doing now...
I''m basically having a main listening port which people connect to. This port does very little except for send the user a dedicated port number for them to use and then the client program reconnects to that port and then the server starts questioning them. That way each user is connected to the server on their own port.
However, as _Stinger said, I should perhaps be making every one come through one port in which case I''m going to need to modify my API calls a little.
Is there any disadvantage to using loads of ports rather than just one if my server is going to be entirely dedicated to one application?
I''m basically having a main listening port which people connect to. This port does very little except for send the user a dedicated port number for them to use and then the client program reconnects to that port and then the server starts questioning them. That way each user is connected to the server on their own port.
However, as _Stinger said, I should perhaps be making every one come through one port in which case I''m going to need to modify my API calls a little.
Is there any disadvantage to using loads of ports rather than just one if my server is going to be entirely dedicated to one application?
Some things have been mixed up here...
A port is a way of naming a machine. If you compare it to the RL mail system, the IP address would be the house the receiver lives in, while the port number would be the name of receiver.
So basically, you can have as many connections on a single port as you want, but youo can only have a single connection between a pair of IP/port-addresses. If you have bound to port :80 of your machine, you can server as many connections as you want, but you can''t have two connections to 24.23.22.21:1156 at the same time.
The other issue are sockets. Sockets are the way OSs present net connections to the programmer. The rule for TCP/IP-sockets is:
One socket is either unconnected, in listen-mode, or connected to exactly one peer. Now if you want to listen, you can only bind() a single socket to a port. However, as soon as you accept() a connection, the socket is cloned: the original socket is still listening on that port, while the new socket is your handle to the connection. Both sockets use the same port though.
Now if you start a connection, you can only have one socket per port due to the way BSD sockets are laid out (at least I think so). However, if you initiate a connection, you usually don''t bind() anyway: in that case, the OS will pick a (more or less) random, unused port for you.
If you''re using UDP, sockets aren''t connected anyway, but the app handles everything that has to do with connections. In a UDP scenario, you usually have a single socket bound to a single port.
So basically, you don''t have to worry about port limitations. What you do have to worry about are socket limitations. For example, in Linux sockets are file descriptors, and the fd limit is somewhere around 250 per process (you can change it with a kernel recompile).
Generally, if you want to write a huge server that is intended to serve a virtually infinite amount of clients (e.g. a master server, or maybe a MMO server - although MMO would fare better with several distributed servers) you''re better off using UDP.
(BTW, I''ve referred to BSD sockets above; WinSock is based on BSD, only the async socket stuff is different, but that isn''t really important for this discussion)
cu,
Prefect
One line of sourcecode says more than a thousand words.
A port is a way of naming a machine. If you compare it to the RL mail system, the IP address would be the house the receiver lives in, while the port number would be the name of receiver.
So basically, you can have as many connections on a single port as you want, but youo can only have a single connection between a pair of IP/port-addresses. If you have bound to port :80 of your machine, you can server as many connections as you want, but you can''t have two connections to 24.23.22.21:1156 at the same time.
The other issue are sockets. Sockets are the way OSs present net connections to the programmer. The rule for TCP/IP-sockets is:
One socket is either unconnected, in listen-mode, or connected to exactly one peer. Now if you want to listen, you can only bind() a single socket to a port. However, as soon as you accept() a connection, the socket is cloned: the original socket is still listening on that port, while the new socket is your handle to the connection. Both sockets use the same port though.
Now if you start a connection, you can only have one socket per port due to the way BSD sockets are laid out (at least I think so). However, if you initiate a connection, you usually don''t bind() anyway: in that case, the OS will pick a (more or less) random, unused port for you.
If you''re using UDP, sockets aren''t connected anyway, but the app handles everything that has to do with connections. In a UDP scenario, you usually have a single socket bound to a single port.
So basically, you don''t have to worry about port limitations. What you do have to worry about are socket limitations. For example, in Linux sockets are file descriptors, and the fd limit is somewhere around 250 per process (you can change it with a kernel recompile).
Generally, if you want to write a huge server that is intended to serve a virtually infinite amount of clients (e.g. a master server, or maybe a MMO server - although MMO would fare better with several distributed servers) you''re better off using UDP.
(BTW, I''ve referred to BSD sockets above; WinSock is based on BSD, only the async socket stuff is different, but that isn''t really important for this discussion)
cu,
Prefect
One line of sourcecode says more than a thousand words.
Ehh.. I''ve taken so long to write my post that I didn''t see the other reply.
Just have one listen-socket, and use the socket returned by listen() to communicate with the client. Redirecting to another port is completely unnecessary, it might even take up more OS resources - and it''ll introduce potential troubles with firewalls. (You''ll know what I mean if you''ve ever tried to use FTP across a firewall)
cu,
Prefect
One line of sourcecode says more than a thousand words.
Just have one listen-socket, and use the socket returned by listen() to communicate with the client. Redirecting to another port is completely unnecessary, it might even take up more OS resources - and it''ll introduce potential troubles with firewalls. (You''ll know what I mean if you''ve ever tried to use FTP across a firewall)
cu,
Prefect
One line of sourcecode says more than a thousand words.
You see, assuming you''re using TCP, you''re doing extra work that you don''t need to do 
WSAAccept(), like standard accept(), returns you a new socket to work with. That new socket will already be connected to a new port on your side. Therefore you don''t have to negotiate yet another new one after you''ve called accept() or WSAAccept().
Sequence of actions:
Server opens a port for listening. (Example: port 80).
Client connects to port 80. A random port on the client''s machine is now connected to port 80 on the server.
Server accepts the connection. This tells the client that the connection has been established, and returns a new socket with a new port on the server side. A random port on the server is now connected to that random port on the client side. Port 80 is now free again.
Repeat for each client.
This is accomplished via the listen, connect, and accept commands. (Add a WSA prefix for Winsock.)
WSAAccept(), like standard accept(), returns you a new socket to work with. That new socket will already be connected to a new port on your side. Therefore you don''t have to negotiate yet another new one after you''ve called accept() or WSAAccept().Sequence of actions:
Server opens a port for listening. (Example: port 80).
Client connects to port 80. A random port on the client''s machine is now connected to port 80 on the server.
Server accepts the connection. This tells the client that the connection has been established, and returns a new socket with a new port on the server side. A random port on the server is now connected to that random port on the client side. Port 80 is now free again.
Repeat for each client.
This is accomplished via the listen, connect, and accept commands. (Add a WSA prefix for Winsock.)
Author
Cheers...that cleared quite a few things up.
So let me recap too see if I''ve got this right....
So first I begin by setting up a socket to listen and do this by
1. Make a socket
2. Bind the socket to the adapter on one port i.e. 80
3. and then set that socket to listen...
4. and make an event when someone connects to that socket...(WSAAsyncSelect does this I think)
then someone connects.....
5. we accept the connection using accept passing the socket that is bound to the port in 2. and it returns a clone of this socket.
6. Then I send messages using this new socket for a parameter in the SocketSend API call...
then someone else connects....
7. and the oldest socket is still bound to the adapter and I get another clone of that but this time it refers to someone else...
is that right?
So let me recap too see if I''ve got this right....
So first I begin by setting up a socket to listen and do this by
1. Make a socket
2. Bind the socket to the adapter on one port i.e. 80
3. and then set that socket to listen...
4. and make an event when someone connects to that socket...(WSAAsyncSelect does this I think)
then someone connects.....
5. we accept the connection using accept passing the socket that is bound to the port in 2. and it returns a clone of this socket.
6. Then I send messages using this new socket for a parameter in the SocketSend API call...
then someone else connects....
7. and the oldest socket is still bound to the adapter and I get another clone of that but this time it refers to someone else...
is that right?
That''s what you need to do IF you want TCP connections - which you generally don''t for a game :p.
A TCP connection requires 3 sockets to create a connection. A UDP connection requires 2, one socket (total) on the server, and one socket on each client. Every client sends data to the same port on the server. So long as no hacker is doing anything underhanded, every packet received will identify the sender.
There are TCP ports and UDP ports. Considering that each socket gets about 32k for it''s packet buffer, UDP offers considerable memory savings for mmog''s (since you only need 1 server socket, instead of one server socket / client).
Port do sorta have a bandwidth limitation, I''m not sure what happens if a packet is received and the packet buffer is full, it''s probably dropped... which would severely affect the transfer rate.
Magmai Kai Holmlor
- Not For Rent
A TCP connection requires 3 sockets to create a connection. A UDP connection requires 2, one socket (total) on the server, and one socket on each client. Every client sends data to the same port on the server. So long as no hacker is doing anything underhanded, every packet received will identify the sender.
There are TCP ports and UDP ports. Considering that each socket gets about 32k for it''s packet buffer, UDP offers considerable memory savings for mmog''s (since you only need 1 server socket, instead of one server socket / client).
Port do sorta have a bandwidth limitation, I''m not sure what happens if a packet is received and the packet buffer is full, it''s probably dropped... which would severely affect the transfer rate.
Magmai Kai Holmlor
- Not For Rent
Author
Well I appear to have got my TCP/IP control sorted after an evening of hard work. It now works PROPERLY! My only quiz is that is there anyway to send extended data with WSAAsyncSelect()? I''m using this to notify my application of a connection, or data arrival. However, at the moment I''m using an array of text boxes for the hwnd parameter in order to identify which socket is sending this data. There seems to be no way to add send parameters with the message, nor to work out which socket raised the message. At the moment I''m identifying it by the array Index which cannot be good...!
UDP eh....I did think about this but it didn''t really seem like anyone much used it. However, since you recommend it I might take a trip around the tutorials to find out about it!
UDP eh....I did think about this but it didn''t really seem like anyone much used it. However, since you recommend it I might take a trip around the tutorials to find out about it!
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
