locked
Network monitoring s/w RRS feed

  • Question

  • 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 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.

    Any suggestions (along with explanations) are welcome.

    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).
    Wednesday, May 6, 2009 3:42 PM

Answers

  • 1. Why "client with multiple servers" approach looks better to you than more traditional "server with multiple clients"? You could easily have one server and multiple clients, administration console being one of them. Everything could be done using either approach.

    2. I suggest spending those several hours using the simpler API which is TcpClinet. Later if and only if you need something that is available with Sockets only, you can easily refactor your code to use them instead. Don't worry about things before they come on your way: worries take more time and energy than work.

    3. Multithreading will be needed only if your server has to accept simultaneous connections from multiple clietns - that's not complex, you just fork a thread for each connection and don't share any data between them.

    4. For client I would usggest using simpler synchronous approach, but multithreading may become necessary if you want your user interface to remain responsive while you are doing something over the network. If your in GUI thread (e.g., processing button click), then use asynchronous API. If you in other thread than GUI thread (meaning you are not blocking the GUI while waiting for network), use simpler synchronous one.
    Wednesday, May 13, 2009 11:52 PM
    Moderator

All replies

  • 1. Why "client with multiple servers" approach looks better to you than more traditional "server with multiple clients"? You could easily have one server and multiple clients, administration console being one of them. Everything could be done using either approach.

    2. I suggest spending those several hours using the simpler API which is TcpClinet. Later if and only if you need something that is available with Sockets only, you can easily refactor your code to use them instead. Don't worry about things before they come on your way: worries take more time and energy than work.

    3. Multithreading will be needed only if your server has to accept simultaneous connections from multiple clietns - that's not complex, you just fork a thread for each connection and don't share any data between them.

    4. For client I would usggest using simpler synchronous approach, but multithreading may become necessary if you want your user interface to remain responsive while you are doing something over the network. If your in GUI thread (e.g., processing button click), then use asynchronous API. If you in other thread than GUI thread (meaning you are not blocking the GUI while waiting for network), use simpler synchronous one.
    Wednesday, May 13, 2009 11:52 PM
    Moderator
  • 1. Why "client with multiple servers" approach looks better to you than more traditional "server with multiple clients"? You could easily have one server and multiple clients, administration console being one of them. Everything could be done using either approach.

    2. I suggest spending those several hours using the simpler API which is TcpClinet. Later if and only if you need something that is available with Sockets only, you can easily refactor your code to use them instead. Don't worry about things before they come on your way: worries take more time and energy than work.

    3. Multithreading will be needed only if your server has to accept simultaneous connections from multiple clietns - that's not complex, you just fork a thread for each connection and don't share any data between them.

    4. For client I would usggest using simpler synchronous approach, but multithreading may become necessary if you want your user interface to remain responsive while you are doing something over the network. If your in GUI thread (e.g., processing button click), then use asynchronous API. If you in other thread than GUI thread (meaning you are not blocking the GUI while waiting for network), use simpler synchronous one.
    1. By client with multiple servers, i meant that the exe residing on the client machines would keep listening for the connection from the exe residing on the server part. I think that the other way round would produce problems : i mean the client machines would keep attempting to connect to server as soon as the machine is started. If i follow my approach, the server would connect to any of the listening client machines at will.

    2. Yes, i have already implemented TcpClient rather than Socket. And thanx for your "worry" sentence :)

    3. Multithreading did prove a headache to me - until i thoroughly learnt it. Now, i think i know much of it. I would post a question though, if i face any problem.

    4. I have followed asynchronous approach for both the sides. It did prove a problem initially, but its clear now.
    Wednesday, June 3, 2009 9:05 AM