To quote MSDN's bind documentation for a socket "For TCP/IP, if the port is specified as zero, the service provider assigns a unique port to the application from the dynamic client port range."

Note that this is "new" behaviour on Vista and up, so if you're amusing enough to target XP, XP64 and/or Server 2003, you're going to end up with an interesting selection of reasonably low ports.

I think the architecture where you assign a new port for each new room is a poor match for your hosting environment.

If your router supports a "DMZ host" then you can forward all incoming connections to that host, and it would work -- but then your host would be vulnerable to random service explits on the internet, which isn't particularly a good thing, especially for default Windows machines.

If you absolutely need to spawn a new process per room, then perhaps a proxy architecture would be better. Users connect to a proxy on a known port. The users then give the proxy instructions for what they want to talk to, and the proxy forwards the connection/data. The proxy could also do things like authentication, looking up which process servers what room, etc. You could then have the room processes only listen for local/internal connections (from the Proxy) and you'd be fine. The advantage of a proxy is that it can scale horizontally just fine -- add more servers for rooms easily; add more proxies with only slightly more work (and a load balancer.)

Or, you could just host all rooms in a single process, listening on a single port, and use threading to take advantage of all the CPU power on the host. This would be a more traditional architecture, but it wouldn't easily scale across more than one server.

I'm not to sure how to set up a proxy, do I have a proxy all ready.

In the current setup clients need to send commands to the main server to create or join a room, only then will the main server allocate them a port to send it back with room info.

Am I allowed to dos attack my own server(but doing that could disrupt other trafic may get me 10 years), to see what happens. Because I have a pennding client list, that I could check to see if there is too many clients pending. The server could send back try again later messages to any new client.

Its all just test code at the moment, any way its not to much work to rewrite the server code, after all this is my second attempt I may need to wite a few more designs

I don't think I am up to stopping any attack. Like this, Things like this do they attack the router and isp or my server app.???

So far the server and client is now in a working state, I fixed all issues related to changing Ip for a local or dns network connection, and clients passing white space as name(never thought about that when writting it, until my mate did it and surprised me when there was no log in name, I new straight away what he did, the server has a info window displaying server assigned ID's for logged in clients. My next job is to write code to handle clients that are sending data to slow, I was thinking of just a time out value when up drop the client.

Am I allowed to dos attack my own server

It's called "load testing" as long as you're doing it on the up-and-up. Also, don't do this with any kind of "shared host" or "virtual slice" host -- that would be bad for others sharing the same host.

Things like this do they attack the router and isp or my server app

A distributed denial of service (flood attack) is all about choking of the narrowest pipe between you and the world. Typically, that will be between you and your ISP. Typically, the ISP and others using the ISP will also suffer. One thing ISPs can do is to temporarily cut off any traffic to your IP address from their upstream/peers.

A non-distributed denial of service typically exploit known problems in a service, such that a smaller number of connections can consume disproportionate amounts of resources. For example, if logging in consumes a lot of database resources, someone might write a script that just logs in, over and over, and thus make the database choke up and not let (many) legit users log in. Or they may send a very, very long network packet to your server, which if there's a bug, makes it run out of memory and crash the process.

I was thinking of just a time out value when up drop the client

That's usually a good idea. That being said -- I hope you're using select(), or I/O completion ports (on Windows,) or epoll/kpoll (on UNIX) rather than synchronous read() or recv() from sockets. A client connection is typically a buffer, a pointer to some client state, and a socket. Each time the socket is readable, you call recv() once into the buffer, trying to fill the buffer up. Then you inspect the buffer, and see if there's a full packet in there -- if so, decode that packet, and dispatch it, and look for another packet.

Finally, if you already have a login server, you could just spawn a new process for the room, and let the login server tunnel/forward the data to the room process, using the login server as your proxy. That way, you only need one port open to the internet.

Yep boost::asio is using I/O completion ports.

for the room(thats on the server machine) should I create a Roomclient connect it to the server, on the same machine. then the server can treat the room as a client aswell by sending it messages, or is this a waste of port usage

This means a Room is a client of the server.

And a bit off topic. Should each message be timed or do I send out a heartbeat to each client and time that for slow connections. or other

should I create a Roomclient connect it to the server, on the same machine

That's one of many possible system architectures. That could work fine.

Should each message be timed or do I send out a heartbeat

If your game sends continuous updates (user input, entity updates) then that's heartbeat enough -- when you haven't received any data, or made any progress in the protocol (whatever that means for your protocol) for X seconds, consider the client dead and drop it.

If your game is turn-based or asynchronous (and "rooms" are more like "chat rooms") then you probably want to send a heartbeat message if you haven't sent another message in, say, the last 5 seconds. If you've gone 15+ seconds without receiving anything, drop the client.

Adjust as necessary.