文件
1: 删除的文件
2：新增文件
3：修改文件

注册表
1：删除键值
2：
1:
新增/列表控件为Tab类型的

1: 把文件传到虚拟机，并且执行(正在做ing)
2：监控虚拟机，并且把信息传过来 (做了差不多了)
3: 1，2这个线程之间进行交互
4：完成任何，测试并且使之稳定

出现了一个bug1:

1：当两个Client：一个ftp Client 一个Syssnap Client共同合作的时候，ftp Server传输文件的时候，多了一

个些字节，
而运行Syssnap Client的线程也是不能正常工作

2: 我们只要结果，不要经过!!
   只要经过，不要结果，是彻底失败的理念

3：现在这个线程在轮询的API上，已经彻底失败了

4：现在开始改变设计思路

出现了bug2:

当使用多路复用的时候，原来设计的协议不能使用，当发送数据的速度比接受的速度快时，发送FSSend时，使用

排他方式打开
文件时，Server已经接受完了，而且正在删除，则将出现删除失败的警告!

为了排除bug2，必须使用1）定时器 2）缓冲机制

解决bug1：
其实很简单，只要把waitfor等待的时间设置为慢一些文件就得到解决!

出现bug3：
使用0.2的技术后，还是出现删除retdata.dat错误的情况,

解决的办法：

1：当C要SendData给S的时候，S在等待retdat.dat(ReadData()),

在双方接受文件的时候，也应该使用握手机制，否则，会出现删除失败的情况!!!

出现了bug3：

单个服务器执行的时候没有问题，但是，双服务器执行的时候，出现了问题了!
还有我没有实现以下几个机制：

1）假如发送端比接受端产生的数据快的时候，出现的问题
2）重发机制，缓冲区机制
3）TCB机制，端口的统一地址

4)传输数据时，以一种不定时的扫描请求包来确定对方时候还在线来取代，TCP的状态机！
因此产生不可靠的数据

解决办法：
1）采用特殊的合乎该项目的设计思路，
2）采用TCP的思想，但是程序会更加复杂了

06-6-11

bug1:

bug1:
1: 服务器的健壮的问题，Client在异常的情况下，Sever发生死锁，归根到底是FSocket的状态机模型不完善导

致:

bug2:
1：当Server给Client一个Rep请求时，Client连接超时退出,
   而Server正想等待读取Data.dat，但是已经没有任何Data.dat可以让Server读取了。于是Server死锁

 

06-6-14
出现了bug3！！
对于bug3，我认为是，我的API不是“线程安全”的所导致的, 使用堆来解决线程安全问题！！

06-6-14
一直在线循环 while(1) FSConnect(..),, 而另一端一直在线连是不对的

但为了做可重用的Server，而不得已出的主意，如果以后做成正式的，这个必须需要改变一下！！

 

#include <stdio.h>
#include <windows.h>

// 出于样例，不做任何错误检查及处理
DWORD g_Cookie = static_cast< DWORD >( -1 );
DWORD g_Index = 1;

struct ABCD { long a; };

void CBA()
{
 reinterpret_cast< ABCD* >( TlsGetValue( g_Cookie ) )->a = g_Index++;
 Sleep( rand() % 1000 );
}

DWORD WINAPI AB( LPVOID )
{
 ABCD *pTemp = new ABCD;
 TlsSetValue( g_Cookie, pTemp );
 CBA();
 printf( "%d/n", pTemp->a );
 delete pTemp;
 return 0;
}
void main()
{
g_Cookie = TlsAlloc();

DWORD id = static_cast< DWORD >( -1 );
HANDLE hThreads[4];

for( unsigned long i = 0; i < 4; ++i )
 hThreads[ i ] = CreateThread( NULL, 0, AB, NULL, 0, &id );

WaitForMultipleObjects( 4, hThreads, TRUE, INFINITE );

for( i = 0; i < 4; ++i )
CloseHandle( hThreads[ i ] );

TlsFree( g_Cookie );

}

#ifdef WIN32

#endif

 

06-6-16

FSocket重要特性说明:

1: socket 是listen或者connect一次后，就不需要再次listen和connect和，而目前的fsocket则需要每Send一

次
需要listen和connect来保证数据的准确，从而取代没有“缓冲区”机制的不同

2: socket的Send和Recv函数，在服务器和客户端都可以使用，而FSocket则还区别FSSend函数和FSSendS2C这两

个函数，
主要是因为FSocket还没有分清客户端和服务器的区别，因为还没有bind函数，或者connect和listen也许可以做

这个
工作，只是目前这个工作还没有完成

3: 每次接受数据的大小, 这个很重要,目前服务器和客户端接受数据的buffer要必须一致, 这个和socket又所有

不同

4: 其实以后可以把目前现在的FSListen和FSConnect连接起来，仅仅形成一个FSSend和FSRecv函数

5: fsocket在每次FSRecv的时候进行FSListen(),该函数会删除文件夹所有的文件，但，假如下面的文件无法删

除的话？
   FSRecv就会出错!,也就是说FSRecv()存在着初始化失败的可能

也就是提供3个接口函数(称为版本)

int CreateFSocket(const char* path);

void CloseFSocket();

int FSSend2(const char* buffer,int len,const long timeout);

int FSRecv2(char* buffer,size_t len,const long timeout);

int FSListenEx();

int FSConnectEx();

int FS_GetLastError();

然后提供这4个接口文件,给上层调用

6: fsocket和socket的不同在于，fsocket在每发送一次数据都要进行一次握手，这样可以保证数据的安全，而

没有采用tcp的只要前期的
   3次握手结束了以后就不需要握手而直接发送数据了, fsocket的实现，代码简单，不复杂，也能保证数据的

正确!
   相当于在udp的基础上+包的确认!

 

 

7: 监控协议的问题

1: 用户可以随意,任何时间让，服务器反馈出监控结果！！
使用方式

int Realdy(),    查询服务器监控是否已经准备好?
int RetResult(char* buffer); 函数，就可以返回监控结果，如何服务器未准备好，则返回错误

8:
06-6-21  
  if (!strcmp(buffer, FSFTPPATH))
  {
   if (FSRecv2(buffer, BOCKSIZE, -1))
   {
    memset(FileName, 0L, 256);
    strcat(FileName, "c:");
    strcat(FileName, buffer);

    if (strcmp(buffer, "//"))
     strcat(FileName, "//");

    if (!CreateDirectory(FileName, NULL))
    {
     fs_error = FS_ERROR_FTP_CREATEDIR;
     return 0;
    }
   }
   continue;

  }

 

该代码有一个bug

06-6-22

今天犯了一个大错误, 需求不明！，不明确自己今天应该干什么？
其实已经明确了，但是，对自己的编程能力缺乏必要的估算，导致问题没法解决！
今天计划把在线监控和过滤加上，但是，ftp的不稳定已经影响在线过滤的的添加!

06-6-23
1：有发现了一个bug，当share/command中的文件，莫名其妙被进程锁定的时候，整个机制将无法进行下去了！
2：如果自己写一个文件系统，让文件在里面一个文件里面进行活动，但是，该文件系统数据，还有有可能被锁

定
   问题找到了，使虚拟机占用了该文件以致不能删除，虽然有关进程都已经关闭，如Server_S等,
   不过写文件系统可以让程序更为健壮一些，虽然还是回遇到文件所特有的缺点！

 

//the driver detect the system and write log
HANDLE hEvent_Detect;
int bCapture = 1;
unsigned int _stdcall Detectinfo(void* pvoid)
{
 char Regbuffer[REGBUFFERSIZE];
 memset(Regbuffer, 0L, REGBUFFERSIZE);

 if (!RegmonInit())
 {
  FS_Trace_Log("c://main.txt", "Detectinfo: RegmonInit error/n");
 }

 FILE* fp = fopen(REPORTLOG, "w+b");

 for(;;)
 {
  if (WAIT_OBJECT_0 == WaitForSingleObject(hEvent_Detect, 300))
  {
   break;
  }

  if (!bCapture)
  {
   if (!UnRegcapture()) return 0;
  }

  if (!RegmonGetInfo(Regbuffer, REGBUFFERSIZE))
  {
   FS_Trace_Log("c://detectinfo", "RegmonGetInfo: RegmonGetInfo error/n");
   return 0;
  }
  
  fwrite(Regbuffer, sizeof(char), strlen(Regbuffer), fp);
  fflush(fp);

  Sleep(1000); 
 }

 UnRegmonInit();
 
 fclose(fp);
 return 0;
}
在工作中，一般是半个月，就可以询问组长自己的表现如何？
然后在这半个月中，争取向组长汇报工作情况3次以上，
有一次都有一个好的演示？这样的的话，争取一个好的印象！

HANDLE  __hStdOut;
FILE* __fStdOut;

void StartConsoleWin(int width, int height,char* title, char* fname)
{
 AllocConsole();//分配
 SetConsoleTitle(title);
 __hStdOut = GetStdHandle(STD_OUTPUT_HANDLE);//指明句柄为标准输出HANDLE
 COORD co = {width,height};
 SetConsoleScreenBufferSize(__hStdOut, co);//指明缓冲区大小
}

#define CPRINTSIZE 1024*200

int cprintf(char *fmt, ...)
{
 char s[CPRINTSIZE];
 va_list argptr;
 int cnt;

 va_start(argptr, fmt);
 cnt = vsprintf(s, fmt, argptr);
 va_end(argptr);

 DWORD cCharsWritten;

 if(__hStdOut)// 写Console
  WriteConsole(__hStdOut, s, strlen(s), &cCharsWritten, NULL);
 return(cnt);
}

06-6-22日

出现一个bug，原来在console模式下的线程安全，在GUI的线程模式下不安全了

06-6-23日

很多测试中的bug都是
 strcpy((char*)pvoid, "c://filereport.txt");
 FS_Trace_Log("c://main.txt", "Leaves ParserFileinfo()");

 return 0;

由于return 0产生的，，

应该return 1这样是最好的

int A()
{
 return 1;
}

 

 

 

编程中的一个bug
复制粘贴又有了bug了
 if( !LoadDeviceDriver(FILE_SYS_NAME, driverPath, &hFileHandle, &error ) ) 
 { 
  FS_Trace_Log("c://main.txt", "LoadDeviceDriver() Error");
  DR_TRACE2("File LoadDeviceDriver Error!");
  return 0;
 }
编程中，最好减少copy-parse的次数，目标是没有

 

 

06-6-23
遇到了一个不可重现的bug，就是22遇到的文件被锁定而不可删除的问题
这个bug称之为“虚拟机-主机共享bug”，
当主机高速产生文件的时候，VM和HM，并没有同时看见该文件，VM的Services
发现该文件时，但，VM的Service却不能将该文件显示，这样导致了：
rep.dat文件被VM的Service所占用，而VM的Server却不知道，所以在等待，

而，主机也在等待，程序出现了死锁！

当然了这个只是猜测，详细地原因还等待编写程序去具体验证

这个bug给我一个深刻教训就是：

1）做程序前，深刻地理解你所依赖的平台
2）清楚你使用平台所依仗的东西！
3）清楚地知道，可能会出现的问题！，问题虽不需要及时解决
   但要知道问题的所在。

6-29:

1: 不应该每次发送数据的时候，都要握手
2：应该把定时器添加进入，取代Sleep
3：应该添加动态多目录的特征，才能使每次发送文件的时候
   每次使用的端口都不一样

 

6-29:
1: 开始觉得务必添加动态多目录了，这样才能写好异步服务器，才能把服务器完善
2: 自己写线程安全辅助函数，不使用windows TLS函数

6-30
程序是我以线程进行耦合的
所以着力点在线程里面

1: 在进行信息过滤的时候，最好在前台做过滤，这是由于不能把过滤得负担加在后台虚拟机上
2：但是呢，从过滤的角度来看，这是不对的，必须是在后台做过滤，目前暂时做一个权宜之计

做过滤的时候解决了一个bug
一次分配却多次使用，出现了bug

在往vector里面压入pointer的时候，千万要小心

3: 做监控的时候，explore在高速的读写注册表, 目前暂时把explore读写注册表的信息忽略

4: 现在我面临两种选择
  1）在后台做过滤
  2）在前台做过滤

 

  1）坏处是程序耦合强，增加程序编写和调试的困难哪
  2）坏处是产生的数据量大，处理时间长，但程序容易编写，调试方便

  为了让程序可用，加快分析，过滤速度，我采用了1)种方式

 

5: fsocket有什么优秀的功能呢？

 

6: 7-3日

1：暂时不具备这样的功能，另起一个线程，线程还是使用主线程的监控文件夹，
   而主线程启动另一个子线程来接受的数据，该监控文件夹不能是主文件夹

2: 今天又两个bug一个出现在GetResCode， 没有return 1，
   一个是在Parsereginfo上，用fopen ，w+b模式打开，原来的数据被覆盖

3: 下一步需要修改的FSocket重要特征是动态目录

1)如果按照王所说，虚拟机和主机不能对同一个文件进行读写那么，则需要以离散文件的形式
  进行通讯了

 

2)如果支持动态目录则，整个程序的架构都需要变化了，
是否需要这样做还得看王的意思

3)文件夹监控，太有威力了，我对他的敬仰如滔滔江水，连绵不绝，黄河泛滥一发不可收拾
 //20指最大的驱动
 //当前驱动监控d:文件夹 d: 8
 //当前文件夹c:为4
 //如果同时监控那么应该是多少呢?

 

7-4
bug1：碰到一个很奇怪的问题

就是，Filemon程序，监控到的数据，和我的程序监控到的数据不一样, 这个是为何呢?

bug1:
暂时忽略，

回到，动态目录和双向自由传送问题上来1

//其实不需要身份认证啊
1：data1.dat client向server发送的数据
2：data2.dat client收server过来的数据

3：data3.dat server向client发送的数据
4：data4.dat server收client发送的数据

目前的技术可以做到双向数据传送了

Clinet:

FSSend() //data1
FSSend() //data1
FSRecv() //data3

server

FSSend() //data3
FSSend() //data3
FSRecv() //data2

5: 想做动态目录，但是，目前的程序基于静态目录，该起来需要一定的时间

又一个沉痛的教训：
1：昨天和前天的近1000行代码又不见了，郁闷啊!!!!!!!

7-5
提高编程能力的一些建议和想法

1: 函数内变量的命名
2：函数名的命名
3: 各种参数结构等的命名

指针的指针有两层概念，
1：这个是指针指向的地址有指，指针不为NULL
   1)指针指向的值为0
   2）指针指向的值不为0
2: 指针不指向任何地址，指针为NULL

以c的观点来做这个程序的话

1：提供好信息通讯的api      几个函数
2：监控好信息并过滤成为文件，几个函数
3：把文件信息传回主机      几个函数

也就是几个函数而已，就可以完成目前的工作了

如果使用c++的观点，就很容易过度设计：

拿起c++的武器，很容易就，服务，对象，继承，分割一些乱七把遭的东西，而对其中用的算法和数据结果只字不提

当时我在想,如果fwrite的操作如下:

fwrite(buffer, size_t, size_t, FILE* pf),将数据buffer,写在fp文件当前指针的位置,而指针位置之后的数据将被删除,

如果,只支持这样的接口的话,我无法使用fwrite来写一个fsocket所使用的socket, 但是后来发现,其实,c库将

数据组织得和memroy一样,其实可可以在文件上进行链表式的遍利和查找.,甚至用户可以像操作内存一样操作

磁盘上的数据