Solid Fluid System Solutions  
Home Software About Hardware Firmware

Document Icon VConsole (Library)
Document Icon Crypto
Document Icon Archive
Document Icon Container
Document Icon Pipe
Document Icon Compress
Document Icon Math
Document Icon Vector
Document Icon DateTime
Document Icon List/Array
Document Icon HashIntegerFloat
Document Icon Database
Document Icon Thread
Document Icon String
Document Icon Machine
Document Icon Regex
Document Icon SGMLParse
Document Icon HTTPHeader
Document Icon Comm
Current Document Icon Collab
Document Icon HierAgent
Document Icon Resource
Document Icon Colour
Document Icon Image

Collab

The collab group is intended as an extension to the Comm group. It's focus is on the provision of a generic client/server interface. It uses VComm subclasses for communication, and consequently it can be tunnel, pipe or socket based. The functional group is based around the idea that the server side application will be implemented as a windows service (no GUI), but the client side could either be a console or a GUI application.

The overall interfaces either side of the link are windows message based, but there is a generic framework that provides an application base class at the client end, and allows development of a function call oriented interface, which manages blocking and marshalling. The same base interface also manages errors from the server and provides a scheme for a "wait prompt" to be automatically displayed whilst the function call is awaiting results from the server.

A generalised user management facility works in conjunction with the comm object security. A user must authenticate before being able to communicate further with the server. A significant role for the collab group is the authentication of users and the storage of user information. Standardised functionality is provided for creating and managing users. Ultimately it should not be possible for password data to be compromised, but for safety, it is one way encrypted. There is no known way for a user password to be established, with the exception of a brute force attack.

Currently user management offers only a simple two tier user scheme. The server messaging scheme always makes the server aware of the name and class of the user associated with the message it is currently processing. The server messaging scheme supports more than two classes of user, but the actual user manager only supports two. This can be useful in circumstances where the server is allowed to perform administrative actions under remote instruction from the client. The main difference, however, between the two classes of user supported by the user manager, is that a primary user can add and administrate other users. A secondary user may not do this.

Copyright © Solid Fluid 2007-2022
Last modified: SolFlu  Mon, 08 Jun 2009 18:18:24 GMT