By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,866 Members | 1,704 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,866 IT Pros & Developers. It's quick & easy.

validating client in socket communciation

P: n/a
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.
Oct 23 '08 #1
Share this Question
Share on Google+
5 Replies


P: n/a
On Wed, 22 Oct 2008 22:47:10 -0700, Nash <je******@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
Oct 23 '08 #2

P: n/a
On Oct 23, 12:25*pm, "Peter Duniho" <NpOeStPe...@nnowslpianmk.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
Nov 3 '08 #3

P: n/a
On Sun, 02 Nov 2008 22:09:52 -0800, Nash <je******@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
Nov 3 '08 #4

P: n/a
On Nov 3, 1:49*pm, "Peter Duniho" <NpOeStPe...@nnowslpianmk.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?
Nov 3 '08 #5

P: n/a
On Mon, 03 Nov 2008 02:40:12 -0800, Nash <je******@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
Nov 3 '08 #6

This discussion thread is closed

Replies have been disabled for this discussion.