文件系统观察器 [英] File System Watcher

问题描述

大家好，

我在codeproject上找到了一篇与所需内容相似的文章，
监视可移动设备上的文件活动
现在，我将如何使这种应用程序在许多网络计算机上运行?所有网络计算机都在Windows上运行，服务器在Windows Sever 2008上运行.

请帮忙.

Hey all,

I had found an article on codeproject that is similar to what is need,
Monitoring file activity on removable devices
Now, how would I make this kind of an application work a number of network computers? All network computers are running on windows and server is running on windows sever 2008.

Please help.

推荐答案

显而易见的解决方案是:

1)以Windows Service的形式开发文件监视程序.
2)在服务中，开发发布者－订阅者，该服务应充当订阅者服务(通过网络提供订阅/取消订阅操作).
3)订户服务应支持代表一个订户的一组远程套接字，应与每个订户建立一个新的TCP会话.
4)Windows Service的发布者部分应处理来自File Watcher的事件(应为单独的线程)，并通过各自的TCP会话将文件系统修改事件分发给所有订阅者；只有一个线程应支持向所有订阅者分发事件的协议.
5)交换协议应要求每个订户发送对收到的每个事件的确认.由于网络异常，应将订户从订户的集合中删除；无论客户端断开连接的原因是什么，都可以通过这种方式保持平稳的操作-客户端系统关闭，损坏，客户端应用程序关闭等.

基本上就是这样.所有这些都需要固定数量的线程(固定的，没有许多客户端尝试设计的每个客户端一个线程的东西-很重要！)，认真的线程同步设计，基于TcpListener和TcpClient的联网.发布者订阅者仅需要两个线程:一个线程正在侦听新连接，另一个线程向/从客户端发送/接收文件系统事件/确认.

整个架构-相当不错.可能需要2-3周.需要帮忙? :)

[更新]

让我们问为什么这样的项目实际上可以有用?经过一番思考，我会说:不多.我面对的是基于发送文件，检测到达情况并基于它们生成一些消息的商业生产环境.一切都是基于文件交换的非常草率的旧版软件的结果.系统集成需要检测文件系统中的更改.它永远不可能是一个合理甚至可以接受的解决方案.从技术上讲，使用我描述的配方是完全有可能的.实际上，这仅表示整个系统的体系结构非常差.计算机系统被设计为隔离的，将文件系统事件暴露给另一台计算机将是不安全的做法.

单台计算机上的File System Watcher可能非常有用.一种应用:对某些软件在幕后所做的事情进行黑匣子调查，尤其是诸如安装程序之类的软件.我几乎无法想象对网络有用的应用程序.

Obvious solution is this:

1) Develop file watcher application in the form of Windows Service.
2) In the service, develop publisher-subscriber, the service should act a a subscriber service (serve up subscribe/unsubscribe operation via network).
3) A subscriber service should support a collection of remote sockets representing a subscriber, a new TCP session should be established with each subscribers.
4) A publisher part of the Windows Service should process events from the File Watcher (should be a separate thread) and distribute the file system modification events to all subscribers via respective TCP session; only one thread should support the protocol of distribution of the event to all subscribers.
5) The exchange protocol should require every subscriber to send confirmation of each event received. The subscribers should be removed from the subscriber''s collection on network exception; this way smooth operation will be maintained whatever the reason for the client disconnection is -- client system shutdown, broken, client application closed, etc.

Basically, that''s it. It all needs fixed number of threads (fixed, no such thing as a thread per client as many try to design -- important!), serious design of thread synchronization, networking based on TcpListener and TcpClient. Publisher subscriber needs just two threads: one listening for new connection, another one sends/receives file system events/confirmations to/from clients.

Whole architecture -- quite a work. Maybe, 2-3 weeks. Need help? :)

[UPDATE]

Let''s ask why such project can be useful practically? After some thinking, I would say: not much. I faced with business production environments based on sending files, detecting the arrival and generating some messages based on them. Everything was a result of very sloppy legacy software based on file exchange. Detection of changes in file system was required for system integration. It can never be a reasonable or even acceptable solution. Technically, it''s quite possible, using the recipe I described. Practically, that would simply indicate extremely bad architecture of the whole system. Computer systems are designed to be isolated, exposing the file system events to another computer would be dirty unsafe practice.

A File System Watcher on a single computer can be very useful. One application: to conduct black box investigation of what some software is doing behind the scene, especially software like installer. I hardly can imagine useful application for a network.

这篇关于文件系统观察器的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！