Network monitoring s/w in C#

[Bhoot]

Currently I have started with my college project - Network monitoring, which may include features like keylogging, application blocking, h/w restrictions, catching snapshots, file operations surveillance, etc. (i mean as many as i would be able to add.)
The platform for this project is C#.NET which is new to me. I have been learning it since past 2-3 days.

I am currently facing a bit weird (atleast to me) kind of situation :
In my project, the interface that an administrator would be using, is actually the client interface, i.e., the server PC would contain the client part of the project.
On the other hand, the server part would be installed in all the PCs(clients) which the administrator would like to monitor.
This is a kind of MULTIPLE SERVERS SINGLE CLIENT situation (atleast i assume so.)

I am stuck in deciding whether i should use synchronous or asynchronous mode of socket programming.According to me, mostly the kind of operations i would be handling would mainly be a single server-single client type : the client interface would deal with any one server at a time. (correction to my assumption are welcome.) So i think synchronous programming would suffice.

Next doubt (mainly addressed to C# programmers) is whether i should use TcpClient class or directly the "raw" Socket class for programming. I spent several hours trying to solve this dilemma, but couldnt get any solution. TcpClient is easier to use; but i may need to use the functionalities that Socket class provides over TcpClient.

Also, would i have any need for multithreading? I think i wont require it because basically what i am dealing with would be single server-single client (a server on a node would handle the only client).

Any suggestions (along with explanations) are welcome. :)

[sknake]

On the client side your best bet would be a synchronous socket, as you suggested. TCP is a stateful protocol so you can't very well send two packets at the same time on the same connection, you need to send one then the next. If it were UDP then you could use asynchronous, but UDP does not guarantee data transmission so log entries could be dropped by the network.

On the server side you should use asynchronous sockets in a single thread. Think about scalability... If you have 50 client machines then that would require 50 threads on the host.. and performance would be horrible. You're better off to use async and deal with the interrupts.

As for using a Socket or TcpClient ... it depends on the functionality you require from the socket.

[Bhoot]

On the client side your best bet would be a synchronous socket, as you suggested. TCP is a stateful protocol so you can't very well send two packets at the same time on the same connection, you need to send one then the next. If it were UDP then you could use asynchronous, but UDP does not guarantee data transmission so log entries could be dropped by the network.

On the server side you should use asynchronous sockets in a single thread. Think about scalability... If you have 50 client machines then that would require 50 threads on the host.. and performance would be horrible. You're better off to use async and deal with the interrupts.

As for using a Socket or TcpClient ... it depends on the functionality you require from the socket.

i would like to heed your attention to one thing here :
i would STRICTLY have ONLY ONE CLIENT (the User Interface which the administrator would be using) in this project; and there are multiple servers to handle (quite contrary to the common single server- many client architecture). The UI would send request to server(s) for some function. So i am skeptical about what you said for the server side (asynchronous).
However, if i am wrong, then please correct me. :)

[sknake]

So this project is more like connect to a machine and watch, not all clients connect to a server to report in?

But if it is a 1:1 relationship between client:server then you don't need to have async sockets, you can use sync. Your design model will either be a single thread with async sockets, or two threads with sync or async.

I would use two threads... one for the UI, one for the network. It will probably be easier to use sync sockets/blocking calls and you can always change it down the road if you want.

[Bhoot]

So this project is more like connect to a machine and watch, not all clients connect to a server to report in?

But if it is a 1:1 relationship between client:server then you don't need to have async sockets, you can use sync. Your design model will either be a single thread with async sockets, or two threads with sync or async.

I would use two threads... one for the UI, one for the network. It will probably be easier to use sync sockets/blocking calls and you can always change it down the road if you want.

yes..i think now you got it right.
This is more like : a UI would keep a watch on all other machines and would ask to perform operations when required.
And based on this, i thought it to be a 1:1 client server. I assume i am thinking right. You may point me out if i am wrong in my assumption.

However, i am skeptical of other thing - what would i do if i would need to send some command (or request!) to all the machines being administered? for eg., if i would like to start keylogging on all the machines; i would just like to hit a "Start All" button. But then would this affect a synchronous model ?

And, i accept your opinion of using two threads on UI side (one for UI and one for network administration). I think i would follow that.

[sknake]

However, i am skeptical of other thing - what would i do if i would need to send some command (or request!) to all the machines being administered? for eg., if i would like to start keylogging on all the machines; i would just like to hit a "Start All" button. But then would this affect a synchronous model ?

Well that is contradicting the 1:1 model you stated in the previous thread, unless you wanted to connect to machine one by one but then the solution would not scale. You could have a Broadcast() method which would hit all of the machines with asynch sockets and do what you will with the response.

[Bhoot]

Well that is contradicting the 1:1 model you stated in the previous thread, unless you wanted to connect to machine one by one but then the solution would not scale. You could have a Broadcast() method which would hit all of the machines with asynch sockets and do what you will with the response.

Very sorry to bother you with the following long list of details, i think i should make my situation more clear :
the administering machine would monitor all other machines as you know. That machine would have the UI installed.

The machines being administered would have the main code (i consider it as 'server code') installed : each machine being administered would listen for a request; the administering machine would connect to the machines it would want to.

Then, it would start monitoring the network machines. Here comes the main point : Most of the time, the administering machine would perform an operation/request on/to a single machine being administered. (1 : 1)
However, there would come certain cases where i would like to "broadcast" a message to all the machines being administered.
(1 : many)
Here is my main dilemma.

Would you advise any solution to this?

[sknake]

If the application allows you to take remote control of the machine then you will probably want to block more than one person connecting at a time.

If the client application sits waiting for a connection... then opens up a connection and just spits out log information to the admin server, then there is no reason to not use async sockets and support 50:1 relationship.

Is this a logging utility, or a remote control utility, or both?

[Bhoot]

If the application allows you to take remote control of the machine then you will probably want to block more than one person connecting at a time.

If the client application sits waiting for a connection... then opens up a connection and just spits out log information to the admin server, then there is no reason to not use async sockets and support 50:1 relationship.

Is this a logging utility, or a remote control utility, or both?

as such its both a logging utility (keylogger, snapshots, etc) as well as a remote control utility (eg., I/O restrictions, web restrictions, USB forbiddance, s/w installation restrictions, etc.)

[Bhoot]

you may want to refer to the following site :
www.os-monitor.com

[sknake]

Use async sockets and plan on handling more than one connection across the board. With applications like this people like to play with it in groups. IE you install this in a workplace then the director of every department will want to play with it, most likely at the same time. Likewise if this is for college and you may present your project, you could wire up a few computers where everyone could use. Beyond that the 1:1 will not work because if you are connected to a machine and administering it then you want to send out a "Broadcast" command to all machines to turn on/off a setting, then it would connect to every machine .. but fail to connect to the one you're already administering... unless you add more code to handle that. Just use async sockets and synchronize your read/writes to the configuration file on the client end, since it may have more than one connection

[Bhoot]

Use async sockets and plan on handling more than one connection across the board. With applications like this people like to play with it in groups. IE you install this in a workplace then the director of every department will want to play with it, most likely at the same time. Likewise if this is for college and you may present your project, you could wire up a few computers where everyone could use. Beyond that the 1:1 will not work because if you are connected to a machine and administering it then you want to send out a "Broadcast" command to all machines to turn on/off a setting, then it would connect to every machine .. but fail to connect to the one you're already administering... unless you add more code to handle that. Just use async sockets and synchronize your read/writes to the configuration file on the client end, since it may have more than one connection

Ok. I agree with you. But would you recommend threading in this module? Yaa..async uses threading, but any chance of threading resulting into an overhead in my case?

[sknake]

Yes, threads will negatively impact performance in this case. If you want to send out a single command to turn on logging -- it is a lot overhead to setup and tear down a worker thread for a single task, where as asynch delegate calls will just pop a thread out of the thread pool, get to work, and return it.

Here is more reading on it: http://www.yoda.arachsys.com/csharp/threads/threadpool.shtml

[Bhoot]

Yes, threads will negatively impact performance in this case. If you want to send out a single command to turn on logging -- it is a lot overhead to setup and tear down a worker thread for a single task, where as asynch delegate calls will just pop a thread out of the thread pool, get to work, and return it.

Here is more reading on it: http://www.yoda.arachsys.com/csharp/threads/threadpool.shtml

oh yaa! The thread pooling had just gone out of my mind actually.
And i had also overlooked the delegates - the event handler "dudes".
ok..now i am much clear. :)
And i will refer to the link you posted.
Thank you for rendering your help. :)

[sknake]

No problem, and good luck!

Please mark this thread solved if I have answered your questions.

[Bhoot]

No problem, and good luck!

Please mark this thread solved if I have answered your questions.

yupp...sure.i will do it.