Veridium Software

Scalable IPC Using Asynchronous Named Pipes and IO Completion Ports

hseldon — Sat, 04 Jun 2011 22:12:54 +0000

Introduction

This is a client/server implementation of Inter Process Communication using Asynchronous Named Pipes with IO completion ports to achieve scalability in situations where several applications need to send and receive large chunks of data to each other or to a central (server) application.
Named pipes provide a flexible and rather easy to implement IPC model which has a message read communication mode where a "client" process can send a message to a "server" process and get an answer to that message.
IO Completion ports, though more known for their use with sockets in server applications, can also be used with files, directories and pipes and they provide an efficient way for handling concurrent asynchronous IO requests.

Using the Code

Creating the server:


//this function will be called when a message is received
//and can be given an answer in pAnswerBuf to pass to the sender
VOID WINAPI Callback(
  LPCVOID	pMessage,
  DWORD		dwMessageLen,
  LPVOID	pAns,
  DWORD*	pdwAnsLen)
{

}

CAsyncPipesServer2 myPipeServer;
myPipeServer.Create(_T("SAMPLEIPC1"), Callback);

Sending a message to server:


	CAsyncPipesClient2 myPipe;

	if (!myPipe.SendMsg(_T("SAMPLEIPC1"),
                  (PVOID)pBuff,
                  nLenBuff,
                  szAns,
                  nAnsLen,
                  INFINITE))
	{ .... }

How Does It Work

Server Side

After creating a completion port we create a separate thread for creating pipe instances that will wait for new connections from clients. This thread will create a predefined number of instances and then wait for a signal from the main thread. When new clients connect to the server, using up pending pipe instances, main thread signals the pipe instances thread to create more. This way we don't hold up the main queue polling thread too much and replace the used up pending pipe instances as soon as possible. After that we issue a ReadFile call to read data a newly connected client has sent.

		case OP_CONNECT:
			{
				////////////////////////////////////////////////////////////

				{
					CXCritSec::CLocker (p->m_csOlp);
					--p->m_nPendingConnects;
				}

				p->m_eventMoreConnects.Set();


				///////////////////////////////////////////////////////////

				pOverlapPlus->nOpCode = OP_READ;
				if (!(pOverlapPlus->pBuff = new CBuffer))
				{
					_ASSERT(NULL);
					p->RemoveOverlapped(pOverlapPlus);
					break;
				}

				DWORD dwBytesRead = 0;

				if (!ReadFile(pOverlapPlus->hPipe,
						pOverlapPlus->pBuff->GetPTR(),
						pOverlapPlus->pBuff->GetSize(),
						&dwBytesRead,
						&pOverlapPlus->ol))
				{
					DWORD dwErr;
					if ((dwErr = GetLastError()) != ERROR_IO_PENDING
						&& dwErr != ERROR_PIPE_LISTENING)
					{
						_ASSERT(NULL);
						p->RemoveOverlapped(pOverlapPlus);
						break;
					}

				}
				else //completed immediately
				{
					pOverlapPlus->pBuff->SetCurrLen(dwBytesRead);

					PostQueuedCompletionStatus(p->m_hIOCP,
						dwBytesRead,
						(ULONG_PTR)pOverlapPlus->hPipe,
						&pOverlapPlus->ol);
				}

			}
			break;

Once read is complete we create a new thread in which we will call the callback function supplied during creation of the server this is because we want to return to GetQueuedCompletionStatus as soon as possible otherwise we unnecessarily delay both new connections and pending read/write requests this also allows the callback function to safely do any lengthy operations if needed. After that we write any (answer) data the callback function wish to pass on to the client onto the pipe.

//called from a separate thread upon read completion
void CAsyncPipesServer2::OnRead(SOverlapped* pOlp)
{
	CBuffer myBuffAns;
	DWORD dwAns = myBuffAns.GetSize();

	m_pCallback(pOlp->pBuff->GetPTR(),
				pOlp->pBuff->GetCurrLen(),
				myBuffAns.GetPTR(),
				&dwAns);


	myBuffAns.SetCurrLen(dwAns);
	pOlp->pBuff->Assign(myBuffAns);


	DWORD dwWritten = 0;

	if (WriteFile(pOlp->hPipe,
			pOlp->pBuff->GetPTR(),
			pOlp->pBuff->GetCurrLen(),
			&dwWritten,
			&pOlp->ol))
	{
		PostQueuedCompletionStatus(m_hIOCP,
						dwWritten,
						(ULONG_PTR)pOlp->hPipe,
						&pOlp->ol);
	}
	else if (GetLastError() != ERROR_IO_PENDING)
	{
		//probably pipe is being closed, or pipe not connected
		RemoveOverlapped(pOlp, true);
	}


}

Client Side

There are a couple of ways to send a message to the pipes server, depending on the level of control you want. I wanted to control the timeout for connection establishment and message transfer individually so I am using the second easiest method CreateFile + WaitNamedPipe + TransactNamedPipe. Easiest method being CallNamedPipe which is equivalent to calling CreateFile, WaitNamedPipe, WriteFile, ReadFile and CloseHandle.

BOOL CAsyncPipesClient2::SendMsg(LPCTSTR  pIpc,
		PVOID   pMessage,
		DWORD   dwMessageLen,
		PVOID   pAns,
		DWORD   dwAnsLen,
		DWORD   dwAnsTimeOut)
{
	tstring strPipeName = _T("\\\\.\\pipe\\");
	strPipeName += pIpc;

	HANDLE hPipe;


_BEGIN:

	if ((hPipe = CreateFile(strPipeName.c_str(),
				GENERIC_READ |
				GENERIC_WRITE,
				FILE_SHARE_READ | FILE_SHARE_WRITE,
				NULL,
				OPEN_EXISTING,
				FILE_FLAG_OVERLAPPED,
				NULL)) == INVALID_HANDLE_VALUE)
	{
		if (GetLastError() == ERROR_PIPE_BUSY)
		{
			if (WaitNamedPipe(strPipeName.c_str(), MAX_WAIT_CONNECT))
				goto _BEGIN;
		}
		else
			return FALSE;

		
		//_ASSERT(NULL);

		return FALSE;
	}


	// Pipe connected; change to message-read mode. 
	DWORD dwMode = PIPE_READMODE_MESSAGE; 
	if (!SetNamedPipeHandleState( 
					hPipe,    // pipe handle 
					&dwMode,  // new pipe mode 
					NULL,
					NULL))
	{
		_ASSERT(NULL);
		CloseHandle(hPipe);
		return FALSE;
	}


	OVERLAPPED olp;
	CXEvent eventTransact;

	memset(&olp, 0, sizeof(olp));
	olp.hEvent = eventTransact.GetEvent();

	DWORD dwBytesRead = 0;
	if (!TransactNamedPipe( 
					hPipe,
					pMessage,
					dwMessageLen,
					pAns,
					dwAnsLen,
					&dwBytesRead,
					&olp))
	{
		DWORD dwLastErr = GetLastError();
		if (dwLastErr == ERROR_MORE_DATA) 
		{
			//ReadFile..
		}
		else if (dwLastErr == ERROR_IO_PENDING)
		{
			if (pAns)
				eventTransact.Wait(dwAnsTimeOut);
		}
		else
		{
			CloseHandle(hPipe);
			return FALSE;
		}
	}


	CloseHandle(hPipe); 


	return TRUE;
}

Fast XML parsing using SAX (Simple API for XML)

hseldon — Sat, 16 Apr 2011 15:58:22 +0000

Introduction

SAX (Simple API for XML) is a fast event based interface for parsing XML files sequentially through a set of callback methods. Unlike DOM (Document Object Model) SAX doesn't require memory for in-memory representation of the XML document thus it facilitates handling of large XML files and is best used for extracting small quantities of data from a large XML file.

Main Benefits:

Supports local or web based XML files.
Parsing can be aborted at any point (before the whole document is parsed).
Includes methods for completing transformations and validation.
Lightweight.

Using SAX

It is rather simple to implement SAX. First we implement an abstract COM interface ISAXContentHandler which has members to be called to notify us of different elements of the XML document being parsed. Then we create SAXXMLReader as we would any COM object (using CoCreateInstance) and we set the content handler of the reader (using our aforementioned implementation).

	CoInitialize(NULL);


	ISAXXMLReader* pRdr = NULL;

	HRESULT hr = CoCreateInstance(
					__uuidof(SAXXMLReader), 
					NULL, 
					CLSCTX_ALL, 
					__uuidof(ISAXXMLReader), 
					(void **)&pRdr);

	if (!FAILED(hr)) 
	{
		ISAXContentHandler* pContentHandler = new CSaxContentHandlerImp;
		hr = pRdr->putContentHandler(pContentHandler);

		//SAXErrorHandlerImpl * pEc = new SAXErrorHandlerImpl();
		//hr = pRdr->putErrorHandler(pEc);

		// SAXDTDHandlerImpl * pDc = new SAXDTDHandlerImpl();
		// hr = pRdr->putDTDHandler(pDc);

		if (FAILED((hr = pRdr->parseURL((unsigned short*)pPath))))
			wprintf(L"\nError parsing file, code: %08X\n\n", hr);
		else
			wprintf(L"\n\nSucess\n\n");

		pRdr->Release();
		delete pContentHandler;

	}
	else
	{
		wprintf(L"\nError creating COM object, code: %08X\n\n", hr);
	}

	CoUninitialize();

Now with each new element found a content handler member will be called to tell us about it, for example the following method will be called when a new element is found:

HRESULT STDMETHODCALLTYPE CSaxContentHandlerImp::startElement( 
			/* [in] */ unsigned short __RPC_FAR *pwchNamespaceUri,
			/* [in] */ int cchNamespaceUri,
			/* [in] */ unsigned short __RPC_FAR *pwchLocalName,
			/* [in] */ int cchLocalName,
			/* [in] */ unsigned short __RPC_FAR *pwchRawName,
			/* [in] */ int cchRawName,
			/* [in] */ ISAXAttributes __RPC_FAR *pAttributes)
{
	int nAttrCount = 0;
	pAttributes->getLength(&nAttrCount);


	unsigned short *pAttr = NULL, *pValue = NULL;
	int nAttrLen = 0, nValueLen = 0;


	wprintf(L"Local Name: %s\n", pwchLocalName);


	wstring str;

	for (int i = 0; i < nAttrCount; ++i)
	{
		pAttributes->getLocalName(i, &pAttr, &nAttrLen);
		str.assign((wchar_t*)pAttr, nAttrLen);
		wprintf(L"Attribute Name: %s\n", str.c_str());

		pAttributes->getValue(i, &pValue, &nValueLen);
		str.assign((wchar_t*)pValue, nValueLen);
		wprintf(L"Attribute Value: %s\n", str.c_str());
	}


	return S_OK;
}

References

HTTP Client Using WININET Asynchronously

hseldon — Sun, 20 Mar 2011 11:46:02 +0000

Introduction

WININET is a set of easy to use APIs that enable you to interact with the FTP and HTTP protocols without having to worry about protocol specifications or even Winsock calls. Other WININET benefits include:

Built in caching support
Supports proxy servers
Supports IPv6

Using The Code

Attached with this post is a wrapper class around the WININET API demonstrating how to use it asynchronously, this is how to use the class:


#include "wininet.h"

....

	CWininet myWininet;
	if (myWininet.Connect("http://veridium.net"), 80, _T("AsyncWininet"), 20000)  //timeout
	{
		if (myWininet.SendRequest("/", _T(""), 20000)) //timeout
		//index page, no referer
		{
			char szBuff[1024];

			while ((nLen = myWininet.Read((PBYTE)szBuff, 1024, 20000)) > 0)
			{
				szBuff[nLen] = 0;
				.....
			}
		}
	}

How Does It Work

First we call InternetOpen using INTERNET_FLAG_ASYNC:

	if (!(m_hInstance = InternetOpen(lpszAgent, 
					INTERNET_OPEN_TYPE_PRECONFIG,
					NULL,
					NULL,
					INTERNET_FLAG_ASYNC)))
	{
               return FALSE;
	}

Then we set a callback function that would be called by the system when an asynchronous operation complets:


	if (InternetSetStatusCallback(m_hInstance,
				(INTERNET_STATUS_CALLBACK)&Callback)
				== INTERNET_INVALID_STATUS_CALLBACK)
	{
		return FALSE;
	}

Now in subsequent API calls we pass a predefined flag so that we recognize this operation and this object from inside the callback function:


	m_context.dwContext	= CONTEXT_CONNECT;
	m_context.pObj		= this;

	m_hConnect = InternetConnect(m_hInstance, 
					lpszAddr,
					uPort,
					NULL,
					NULL,
					INTERNET_SERVICE_HTTP,
					INTERNET_FLAG_KEEP_CONNECTION | INTERNET_FLAG_NO_CACHE_WRITE,
					(DWORD)&m_context);

And inside the callback we signal an event for each completed operation to notifiy the waiting thread:

	switch(pContext->dwContext)
	{
	case CONTEXT_CONNECT:
		if (dwInternetStatus == INTERNET_STATUS_HANDLE_CREATED)
		{
			INTERNET_ASYNC_RESULT *pRes = (INTERNET_ASYNC_RESULT *)lpStatusInfo;
			pContext->pObj->m_hConnect = (HINTERNET)pRes->dwResult;
			SetEvent(pContext->pObj->m_hConnectedEvent);
		}
		break;
	......

	}

History

20 MAR 11: first release.

(GDI) Scheduler Control

hseldon — Sat, 19 Feb 2011 21:10:16 +0000

Introduction

This is a simple scheduler control created using plain GDI API. Lines drawing done using MoveToEx and LineTo. Coloring done using FillRect. All wrapped up in one class CScheculerCtrl without any MFC (though the demo project is in MFC).

How to Use

Initialization: (e.g.: in OnInitDialog)


//left margin: 40px, top margin: 25px
m_mySchedulerCtrl.Init(40, 25);

Painting: (e.g.: in OnPaint)

m_mySchedulerCtrl.Paint(dc.GetSafeHdc());

On mouse hover handling (e.g.: in OnMouseMove )

	CDC* pDC = GetDC();

    //rect structs that will hold changed regions coordinates
    //in case you are using a memroy DC and want to only paint updated regions only
    //to the final DC
	RECT rc1, rc2;
	memset(&rc1, 0, sizeof(rc1));
	memset(&rc2, 0, sizeof(rc2));

	m_mySchedulerCtrl.OnMouseMove(pDC->GetSafeHdc(), point.x, point.y, &rc1, &rc2);
	ReleaseDC(pDC);

Mouse click handling, in OnLButtonDown:

	CDC* pDC = GetDC();

	RECT rc;
	memset(&rc, 0, sizeof(rc));

	m_mySchedulerCtrl.OnMouseLClick(pDC->GetSafeHdc(), point.x, point.y, &rc);
	ReleaseDC(pDC);

History

19 FEB 11: first release.

Asynchronous File System Monitoring

hseldon — Thu, 13 Jan 2011 15:19:49 +0000

Introduction

There are 3 main methods for monitoring the file system on a Windows machine. Kernel mode filesystem drivers, the FindFirstChangeNotification API and the ReadDirectoryChangesW API. If the main purpose of your application is not monitoring the file system or bypassing/overriding file system IO operations then Kernel mode file system drivers would be too much unnecessary work. FindFirstChangeNotification is a good alternative but it tells you that a change took place but not which file was changed or how (added, modified, removed..etc.) ReadDirectoryChangesW on the other hand, when called asynchronously, is reasonably efficient and provides detailed info on which file changed and how.

There are also 3 approaches to using ReadDirectoryChangesW asynchronously:

GetOverlappedResult: this requires an event object for each directory you'd like to monitor.
.
Using a completion routine: this requires that you provide a completion function (completion routine) that would be called by the system whenever a change occurs.
.
Using IO completion ports: in this method we associate handles of directories to be monitored with a completion port much like we associate it with sockets. This I think is more scalable/efficient than the two other methods and that's what we are implementing here.

Using the Code


#include "FileSysMon.h"

.....

	CFileSysMon myFileSysMon;
	if (!myFileSysMon.Init())
	{
		MessageBox(0, _T("Initialization Error"), NULL, MB_ICONERROR);
		return 0;
	}


	if (myFileSysMon.AddPath(_T("c:\\FolderToMonitor")) != E_FILESYSMON_SUCCESS)
		MessageBox(hWnd, _T("Error adding file to monitoring list"), NULL, MB_ICONERROR);


	VECCHANGES vecChanges;
	while (myFileSysMon.GetQueuedStatus(vecChanges, INFINITE) == E_FILESYSMON_SUCCESS) //INFINITE or a timeout value in milliseconds
	{
		//vecChanges.at(i).strFilePath
		//if ((vecChanges.at(i).dwAction & FILE_ACTION_ADDED) == FILE_ACTION_ADDED)
		//if ((vecChanges.at(i).dwAction & FILE_ACTION_REMOVED) == FILE_ACTION_REMOVED)
		//if ((vecChanges.at(i).dwAction & FILE_ACTION_MODIFIED) == FILE_ACTION_MODIFIED)
		//if ((vecChanges.at(i).dwAction & FILE_ACTION_RENAMED_OLD_NAME) == FILE_ACTION_RENAMED_OLD_NAME)
		//if ((vecChanges.at(i).dwAction & FILE_ACTION_RENAMED_NEW_NAME) == FILE_ACTION_RENAMED_NEW_NAME)

		.....
	}

How Does It Work

First we create a completion port using CreateIOCompletionPort:

	if (!(m_hIOCP = CreateIoCompletionPort(
							(HANDLE)INVALID_HANDLE_VALUE,
							NULL,
							0,
							nThreads)))
	{
		m_nLastError = GetLastError();
		return false;
	}

Then we associate each directory we would like to monitor with that completion port also using CreateIOCompletionPort:

	if (CreateIoCompletionPort(pDir->hFile, m_hIOCP, (ULONG_PTR) pDir->hFile, 0) == NULL)
	{
		m_nLastError = GetLastError();
		CloseHandle(pDir->hFile);
		delete pDir;

		return E_FILESYSMON_ERRORADDTOIOCP;
	}

And we call ReadDirectoryChangesW on the directory handle:

	if (!ReadDirectoryChangesW(pDir->hFile,
					pDir->pBuff,
					MAX_BUFF_SIZE * sizeof(FILE_NOTIFY_INFORMATION),
					bSubTree,
					dwNotifyFilters, 
					&dwBytesReturned,
					&pDir->ol,
					NULL))
	{
		m_nLastError = GetLastError();
		CloseHandle(pDir->hFile);
		delete pDir;
	
		return E_FILESYSMON_ERRORREADDIR;
	}

Then we query the completion port for status messages:

	if (!GetQueuedCompletionStatus(m_hIOCP, &dwBytesXFered, &ulKey, &pOl, dwTimeOut))
	{
		if ((m_nLastError = GetLastError()) == WAIT_TIMEOUT)
			return E_FILESYSMON_NOCHANGE;
		return E_FILESYSMON_ERRORDEQUE;
	}

History

13 JAN 11: first release.

Asynchronous Client Socket Class Without MFC

hseldon — Fri, 03 Dec 2010 21:48:28 +0000

Introduction

I created this class while trying to avoid having recv hang/block indefinitely in a simple client application I was working on, without using MFC. recv can hang for a variety of reasons most common is untimely calling of recv or calling it when the remote server doesn't send data it was supposed to send, e.g.: because of a malformed request.

Using the code

    
    #include "XSocket.h"
    
    ....
    
	CXSocket mySock;

	if (!mySock.Init()) //initalize winsocks
	    return false; //failed
	    
	//////////////////////////////////////////////////////////////////////////
		
	if (!mySock.Connect(pHostName, nPort))
	{
	    int nError = mySock.GetLastError();
	    return false; //failed to connect
	}
	
	/////////////////////////////////////////////////////////////////////////
	
	// Send a buffer, 5 seconds timeout
	// further error checking omitted for previty
	
	int nLen = 0;
	if (mySock.Send(szBuff, strlen(szBuff), nLen, 5000) != E_XSOCKET_SUCCESS)
	    return false;
	   
 
	/////////////////////////////////////////////////////////////////////////
	
	// Receive server's response, 5 seconds time out
	// last argument is optional, if not used Rec will return immediately
	
	do
	{
	    if (mySock.Recv(szBuff, sizeof(szBuff) - 1, nLen, 5000) 
			!= E_XSOCKET_SUCCESS)
		{
			break;
		}
	}
    while (nLen == sizeof(szBuff));	
    
    
    //////////////////////////////////////////////////////////////////////////
    
    // Optional: explicitly close the socket, if not called socket will be closed
    // auto on destruction
    
    mySock.Close();

Canceling a request, regardless of timeout:

    mySock.Abort();

Checking if there is data available for reading, this can be called at any time after a successful Connect:

long lLen = mySocket.GetLenDataAvail();

Points of Interest

We turn on nonblocking mode for a socket and at the same time attach an event object by calling:

WSAEventSelect(hSocket, hEvent, FD_READ | FD_WRITE | FD_CLOSE)

This will attach hEvent to hSocket so that when there is a new read, write and close event hEvent will be signaled. AlsoWSAEventSelect automatically turns on nonblocking mode for hSocket as well.

Sending Data

Data sending code looks like this:

int CXSocket::Send(const char* pBuff, int nLen, int& nLenSent, DWORD dwTimeOut)
{	

_BEGIN:

	int nRet = 0;
	m_nLastError = 0;

	if ((nRet = send(m_hSocket, pBuff, nLen, 0)) > 0 || (m_nLastError = WSAGetLastError()) != WSAEWOULDBLOCK)
		return E_XSOCKET_SUCCESS;


	///////////////////////////////////////////////////////////////////////////////////

	HANDLE arrHandles[2];

	arrHandles[0] = m_eventNet.GetEvent();
	arrHandles[1] = m_eventStop.GetEvent();

	DWORD dwWaitRes = WaitForMultipleObjects(2, arrHandles, FALSE, dwTimeOut); 
	
	if (dwWaitRes == WAIT_OBJECT_0 + 1)
		return E_XSOCKET_ABORTED;
	else if (dwWaitRes != WAIT_OBJECT_0)
		return E_XSOCKET_TIMEDOUT;


	//////////////////////////////////////////////////////////////////////////////////

	WSANETWORKEVENTS myNetEvents;

	if (WSAEnumNetworkEvents(m_hSocket, m_eventNet.GetEvent(), &myNetEvents) != 0)
	{
		m_nLastError = WSAGetLastError();
		return E_XSOCKET_SOCKERR;
	}

	if ((myNetEvents.lNetworkEvents & FD_WRITE) != FD_WRITE)
	{
		goto _BEGIN;
	}

	if (myNetEvents.iErrorCode[FD_WRITE_BIT] != 0)
		return E_XSOCKET_SOCKERR;


	/////////////////////////////////////////////////////////////////////////////////////

	nLenSent = send(m_hSocket, pBuff, nLen, 0);


	return E_XSOCKET_SUCCESS;
}

What we do here is first issue a Send request, if our request can be fulfilled data will be sent immediately and return value of Send will be the length of data actually sent. Otherwise our request will be queued and Send will return WSAEWOULDBLOCK. The Winsock subsystem will then notify us when it is possible to send our data by signaling the event we attached to the socket earlier. At that point we call WSAEnumNetworkEvents to make sure the event is an FD_WRITE if it is not we continue waiting for FD_WRITE (if dwTimeOut is greater than zero).

Receiving Data

Data receiving code looks like this:

int CXSocket::Recv(char* pBuff, int nLen, int& nLenReceived, DWORD dwTimeOut)
{

_BEGIN:

	///////////////////////////////////////////////////////////////////////////////////

	HANDLE arrHandles[2];

	arrHandles[0] = m_eventNet.GetEvent();
	arrHandles[1] = m_eventStop.GetEvent();

	DWORD dwWaitRes = WaitForMultipleObjects(2, arrHandles, FALSE, dwTimeOut); 
	
	if (dwWaitRes == WAIT_OBJECT_0 + 1)
		return E_XSOCKET_ABORTED;
	else if (dwWaitRes != WAIT_OBJECT_0)
		return E_XSOCKET_TIMEDOUT;


	////////////////////////////////////////////////////////////////////////////////////

	WSANETWORKEVENTS myNetEvents;

	if (WSAEnumNetworkEvents(m_hSocket, m_eventNet.GetEvent(), &myNetEvents) != 0)
	{
		m_nLastError = WSAGetLastError();
		return E_XSOCKET_SOCKERR;
	}

	if ((myNetEvents.lNetworkEvents & FD_READ) != FD_READ)
		goto _BEGIN;

	if (myNetEvents.iErrorCode[FD_READ_BIT] != 0)
		return E_XSOCKET_SOCKERR;


	/////////////////////////////////////////////////////////////////////////////////////

	if ((nLenReceived = recv(m_hSocket, pBuff, nLen, 0)) == WSAEWOULDBLOCK)
	{
		nLenReceived = 0;
		return E_XSOCKET_NOMOREDATA;
	}


	return E_XSOCKET_SUCCESS;
}

What we do is wait for an FD_READ event. If we get it we call recv to read the data available.

History

03 DEC 10 first release.

Home Tab

webadmin — Wed, 10 Nov 2010 15:08:33 +0000

The Home tab shows total monitoring records counts and buttons for stopping/starting monitoring (HomeGuard starts automatically at Windows startup), changing monitoring settings, changing the administrative password, uninstalling HomeGuard and online help.

Features Screenshots Buy Now Help And FAQ

Web Filter

webadmin — Wed, 10 Nov 2010 15:07:17 +0000

This tab shows total time spent on each site visit and program used to access the site. You can view individual pages visited from each site by right clicking the title box and selecting 'View All Files'.

Features Screenshots Buy Now Help And FAQ

Screen Capture

webadmin — Wed, 10 Nov 2010 15:06:44 +0000

Thumbnail view for quickly flipping through many shots and full size view for closer observation. Screen shots can be taken at specific intervals and at specific times of day or days of week (default is all day everyday). HomeGuard can also take shots when an event occurs, e.g.: website visits, keywords...

Features Screenshots Buy Now Help And FAQ

Keylogger

webadmin — Wed, 10 Nov 2010 15:04:39 +0000

Keylogger records show which programs were typed in and program titles at the time of typing.

Features Screenshots Buy Now Help And FAQ