Hey, have you got any suggestions with methods of preventing anonymous connections? With TCP, some things are considerably exploitable. A prime example is the obvious one, once we direct ourselves to "server's ip:port" using an internet browser, it establishes a connection between both network.

I've tried a method where the server checks whether the current socket is connected (using 'tcpconnected' with 39DLL), if it isn't then the server closes the socket. My method did not work, though. However, the results were not of what I've expected; instead of it [socket] being closed it's set to a halt: close_wait.

Converting to UDP isn't an option for me.

Suggestions, please.

I've had to rethink for another implementation and I have. And it worked. So, I'm fine now. Rest be assured for the others to discuss.

Mind posting the solution since others perhaps have the same problem.

Simply, by using security code(s) for both channels to identify eachother. At the beggining, once a client connects to the server, the server checks whether the client has sent the security code, if not then close the socket immidiately, otherwise it continues to assigning the client's ID and occupy a slot. And check afterwards whether the client remained connected, if not then close the socket.

It's a quick fix, really. It isn't reliable enough but I can work my way onto imporving it. As of now, close_wait has changed to fin_wait_2. Which is less of a problem, and besides, the problem occurs on the client's side.

I hope for you that that "security code" cannot be spoofed or be abused (intercepted/(re)created) by a man-in-the-middle attack ...

I could do a random encryption, that should help. And also, I forgot to mention that the code is compared if it is equal to the correct security code.

I haven't any other idea of how else a packet injection could be successful, even if it sends more or less than it needs, it'll be rejected.

The server is coded in C++, would there be any other advantages of this usage?

I've had to review my technique as it didn't work in another situation. The message from client is sent late, and the server ignores it once it checks whether the client has sent something.

How will I implement the server to check whether the connection is still alive, or whether the connection with the client is still active?

I don't understand what the problem is to start with. Once you establish a connection to a server, your NAT (if you have one) will begin forwarding packets from the server back to your computer. That's about all I can think of. TCP itself can not be exploited to execute arbitrary code or otherwise cause harm to a machine. The most common network attacks that worms and such use to spread involve sending specifically crafted steams designed to exploit particular software that may be running on the target computer and listening on some known port.

The only real solution is to make sure your software can't be exploited to start with. Buffer overflows are a big culprit and those generally can't occur in GM.

The server should send out a "heartbeat" packet.

Upon connection, set timer 1, for say 1 minute. When the timer code runs send a "heartbeat packet", all this packet contains is a unique id, indicating it is a heartbeat. After sending the heartbeat, set a timer 2 for say 30 seconds.

When the client receives the heartbeat, all it does is respond with a heartbeat reply message.

When the heartbeat message response is received set Timer 2 to zero and reset Timer 1 back to 60, to start the process over again.

Should Timer 2 expire, it means that the client didn't reply, shutdown it's connection.

The 60 second heartbeat timer and 30 second response wait are arbitrary, you can adjust them as you see fit, another consideration is not to disconnect the client after just 1 lost heartbeat, perhaps a 3 strike-yer-out rule.