let''s say computer number 1 is a server that accepts application at port 5555. it is multithreaded and creates a separate thread for each connection. how many clients can connect to it? can i have 2 or more clients simultaneously connecting at 5555? how will the server know which data going through port 5555 is to which thread? thanks.

Assuming you''re talking about TCP ports, then when a client connects to the server and the server does an accept(), the server allocates a new local port for communication with that client. The client will then send all future packets to the new port, not the port that the server is listening for new connections on. The total number of open connections that a server can run is operating system/protocol stack implementation dependent. In theory it''s limited to a maximum of 65535, which would be the number of valid ports. In practice it will be much smaller than that.

i see...so if i know the new local port being used, can i connect to it directly after the socket disconnects (about a minute or two after it disconnects)? as it seems that the port is free...is it correct to assume this?

thanks!

The new port assigned for the connection on the server will not have a listen() called on it, so trying to connect to it should give a connection refused error. You should only try to connect to the port that the server is actually listening on.

i see. ok thanks!

btw, since the theoretical limit is about 65,000 ports, does it mean i can''t have more than that number of simultaneous incoming connections?

thanks.

The maximum number of simulataneous incoming, unaccepted conncections is dependent on the protocol stack implementation. Don''t expect it to be a very large number.

NOw i gotta ask, that doesnt apply to udp right? it doesnt ask any qyestions, it kinda just takes the data, so theres no real limit... right? and also, what would happen if two packets arrived at the same time?

UDP has no concept of connections, so, of course, almost of all this thread has no bearing on UDP.

There is, in addition to whatever physical bandwidth limitations exist, a protocol implementation defined limit to the amount of unreceived data buffered by the protocol stack. If two packets arrive simultaneously, hopefully both will get placed in the buffer to be read by the application. If a large number of packets arrive before the application reads the packets, some of those packets will be simply dropped.

> that doesnt apply to udp right?

You simply receive the packet and you extract both the data and the sender info via ''recvfrom()''.

> what would happen if two packets arrived at the same time?

That''s a hardware issue; there is nothing you can do in software. With UDP you''ll get lost packets and you would have to build some reliability layer atop your comm code.

> since the theoretical limit is about 65,000 ports

The TCP stack is more than just 65000 integers. Each connection has input and output buffers, state variables, etc. So each socket eats a fair amount of memory; to lower memory consumption you need multiplexing. And threads are not the ideal solution for that because each thread needs stack space and other overhead, not to mention task/thread switching overhead. That''s why modern servers utilize advanced overlapped I/O strategies such as IOCP on Windows and AIO on unix.

-cb

ok thanks guys!