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.

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.

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.