validating client in socket communciation

[Nash]

Hi,
I am using asynchronous client/server communication. Whenever a
client is getting connected to the server the correspoinding socket is
added to the list. I want to validate whether the client is really a
valid one, for that every client will send some command to server for
validation. But the thing is if the client is invalid server will not
receive the command at all so the socket will be kept open how should
i identify that socket and close that invalid socket ?

thanks in advance.

[Peter Duniho]

Re: validating client in socket communciation

On Wed, 22 Oct 2008 22:47:10 -0700, Nash <jeevs007@gmail .comwrote:

Hi,
I am using asynchronous client/server communication. Whenever a
client is getting connected to the server the correspoinding socket is
added to the list. I want to validate whether the client is really a
valid one, for that every client will send some command to server for
validation. But the thing is if the client is invalid server will not
receive the command at all so the socket will be kept open how should
i identify that socket and close that invalid socket ?

I am having trouble understanding your description. In what way can a
client be "invalid" in a way that manages to leave the connection open and
yet fails to transmit your command to the server? How is the client
failing a validation step without sending the command that is supposed to
validate it?

As always, a concise-but-complete code example would be _much_ better as a
way of describing your problem.

Pete

[Nash]

Re: validating client in socket communciation

On Oct 23, 12:25 pm, "Peter Duniho" <NpOeStPe...@nn owslpianmk.com>
wrote:

On Wed, 22 Oct 2008 22:47:10 -0700, Nash <jeevs...@gmail .comwrote:

Hi,
 I am using asynchronous client/server communication. Whenever a
client is getting connected to the server the correspoinding socket is
added to the list. I want to validate whether the client is really a
valid one, for that every client will send some command to server for
validation. But the thing is if the client is invalid server will not
receive the command at all so the socket will be kept open how should
i identify that socket and close that invalid socket ?

>
I am having trouble understanding your description.  In what way can a  
client be "invalid" in a way that manages to leave the connection open and  
yet fails to transmit your command to the server?  How is the client  
failing a validation step without sending the command that is supposed to 
validate it?
>
As always, a concise-but-complete code example would be _much_ better as a  
way of describing your problem.
>
Pete

thanks pete for your response.

what i ment by invalid is some unauthorized client. if some one knows
the ip and port number where server is listening for incoming
connections, they can write a code to connect to the server right.
I want to prevent it, for that what i thought is every authorized
client will send some valid command with wich server will validate. so
server will always send some data to the authrozied client. but the
problem is the hacker program will not send any command for
authroization so that socket will not be closed at all.

is there anyother stragey i should follow to authorize the clients

[Peter Duniho]

Re: validating client in socket communciation

On Sun, 02 Nov 2008 22:09:52 -0800, Nash <jeevs007@gmail .comwrote:

what i ment by invalid is some unauthorized client. if some one knows
the ip and port number where server is listening for incoming
connections, they can write a code to connect to the server right.
I want to prevent it, for that what i thought is every authorized
client will send some valid command with wich server will validate. so
server will always send some data to the authrozied client. but the
problem is the hacker program will not send any command for
authroization so that socket will not be closed at all.

What kind of hacker are you expecting? Will they send _any_ data? If
not, then other than a denial-of-service attack, what would that hacker
expect to accomplish?

is there anyother stragey i should follow to authorize the clients

It really depends on your application protocol. It's entirely possible,
depending on your security needs, that it's sufficient that the client
simply provide valid data. A custom protocol is unlikely to be known by a
hacker, and so they're not going to send valid data.

If you have a custom protocol but data that is sensitive, then
yes...you'll probably want to add a layer of security on top of that.
That way a hacker specifically targeting your server but who is actually
aware of the protocol specifics still won't be able to get data. But, you
should just make the authentication part of the protocol. Any client who
attempts any operation except the authentication step would be dropped.

That then leaves denial-of-service attacks as your main vulnerability.
But that's not something you're going to be able to defend against in your
server. The best you can do there is timeout a connection if there's no
activity after a certain amount of time, but all that does is help the
server clean up from errors, dropped connections, etc.

There's no way to set a timeout that is short enough to deal with DoS and
yet allows a legitimate client to connect. In the server, you could keep
a list of rejected IP addresses (e.g. clients that have been timed out
recently, more than a certain number of times), but a) that may result in
legitimate clients with poor network connections getting wrongly rejected,
and b) you're still going to be limited by how fast your server can reject
connections. DoS attacks are a whole other level of security issue, and
frankly this newsgroup really isn't the best place to learn how to deal
with them.

Pete

[Nash]

Re: validating client in socket communciation

On Nov 3, 1:49 pm, "Peter Duniho" <NpOeStPe...@nn owslpianmk.com>
wrote:

On Sun, 02 Nov 2008 22:09:52 -0800, Nash <jeevs...@gmail .comwrote:

what i ment by invalid is some unauthorized client. if some one knows
the ip and port number where server is listening for incoming
connections, they can write a code to connect to the server right.
I want to prevent it, for that what i thought is every authorized
client will send some valid command with wich server will validate. so
server will always send some data to the authrozied client. but the
problem is the hacker program will not send any command for
authroization so that socket will not be closed at all.

>
What kind of hacker are you expecting?  Will they send _any_ data?  If  
not, then other than a denial-of-service attack, what would that hacker  
expect to accomplish?
>

is there anyother stragey i should follow to authorize the clients

>
It really depends on your application protocol.  It's entirely possible,  
depending on your security needs, that it's sufficient that the client  
simply provide valid data.  A custom protocol is unlikely to be known by a  
hacker, and so they're not going to send valid data.
>
If you have a custom protocol but data that is sensitive, then  
yes...you'll probably want to add a layer of security on top of that.  
That way a hacker specifically targeting your server but who is actually  
aware of the protocol specifics still won't be able to get data.  But, you  
should just make the authentication part of the protocol.  Any client who  
attempts any operation except the authentication step would be dropped.
>
That then leaves denial-of-service attacks as your main vulnerability.  
But that's not something you're going to be able to defend against in your  
server.  The best you can do there is timeout a connection if there's no  
activity after a certain amount of time, but all that does is help the  
server clean up from errors, dropped connections, etc.
>
There's no way to set a timeout that is short enough to deal with DoS and 
yet allows a legitimate client to connect.  In the server, you could keep  
a list of rejected IP addresses (e.g. clients that have been timed out  
recently, more than a certain number of times), but a) that may result in 
legitimate clients with poor network connections getting wrongly rejected,  
and b) you're still going to be limited by how fast your server can reject  
connections.  DoS attacks are a whole other level of security issue, and  
frankly this newsgroup really isn't the best place to learn how to deal  
with them.
>
Pete

Thanks pete for your valuable reply.

I have another question in sockets. my requirement is like a server
that can handle 1 million clients. is it possible to have 1 million
sockets kept open through out or shall the client open the connection
whenever it needs to send data and close it, will there be any
overhead in this process than keeping the connection open forever?

[Peter Duniho]

Re: validating client in socket communciation

On Mon, 03 Nov 2008 02:40:12 -0800, Nash <jeevs007@gmail .comwrote:

I have another question in sockets. my requirement is like a server
that can handle 1 million clients. is it possible to have 1 million
sockets kept open through out or shall the client open the connection
whenever it needs to send data and close it, will there be any
overhead in this process than keeping the connection open forever?

There certainly is significant overhead for each socket that you keep
open. But, performance-wise there is even more overhead opening and
closing connections between the server and the same client over and over.
Unless clients only communicate with the server very infrequently, you
should just keep their connections open.

That said, a server supporting 1 million sockets is going to have to get
_everything_ right. Even at hundreds of thousands of sockets, only by
being very careful about your code can you achieve acceptable throughput.
For 1 million, on top of coding everything perfectly, you'll need a
computer with lots of i/o bandwidth, lots of CPUs, a huge amount of
memory, and a way to service each client i/o operation extremely quickly.

Just being able to keep the sockets open is only a small part of the
battle. Note, of course, that unless you maintain very tiny buffers
(which will be terrible for performance), you're going to need 64-bit
Windows to support that many sockets. (Actually, you might need that many
anyway...I don't have first-hand experience implementing something that
large, so can't say for sure it'd work for you under any circumstances on
32-bit Windows).

If you want to scale up that large on a single server, you should
definitely be looking at the newest Socket APIs for asynchronous i/o.
That is, the methods ending in the word "Async". These are even more
efficient than the previous async methods (methods starting with the word
"Begin"), and I believe that you have no hope of supporting 1 million
simultaneous clients without them, not in .NET anyway.

That's all assuming you can get it to work at that scale at all. I've
only heard of servers at that scale in shops where experts at network i/o
are doing the programming; it's not for the faint of heart, that's for
sure. :)

Pete