Ethereal-dev: [Ethereal-dev] Sponsoring development of SQL Filters & tethereal functionality

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: "Russell Samuels" <russells@xxxxxxxxxxx>
Date: Tue, 31 Aug 2004 13:08:34 -0400
Hi,
 
I'm a project manager with Synomos, and we're considering sponsoring the development of SQL Filtering functionality and some additional functionality for tethereal.  If anyone who's worked on Ethereal for awhile can point me towards the folks with the requisite experience for this, I would much appreciate it.  Please touch base with me directly.
 
Regards,
russells (you can guess my e-mail address from the info provided)
 
http://www.synomos.com 
 
 
High Level Requirements:
 
License Requirements
====================
The tool can be open source or closed source.  Access to and rights to modify the source code is a requirement (in order to meet future needs in the event that development on the product ceases).  It is preferable that source code created in the course of developing the tool is not GPLed, though it is recognized that this is impossible if GPLed code is determined to provide an optimal code base upon which to build the tool.
 

Technical Requirements
======================

1.0  Must provide a means to log sql communications on the wire or via a mirrored switch port
1.1  Must parse the logged data into meaninful categories, and allow the user to display a subset thereof:
     -Time
     -SQL Command / data parameters
     -Transaction# (within any specific session)
     -# Rows returned
     -User login
     -HostID
     -IP Address (client)
     -Port #
     -Application
     -Database error/warnings/messages
     -Server
     -Database
1.2  Must store sniffed data to a database for retrieval by other applications
1.3  Must do all of the above in near-real-time (max-delay of 5 seconds)
1.4  Must be capable of supporting high load db (e.g. thousands per second, with ~1000 unicode characters transaction text per transaction) without losing any transactions
 
2.0  Must be controllable without invoking a gui (e.g. an API to control functionality or command-line driven)
2.1  Must allow the user to configure the following parameters:
     -S <server name>
     -ip <server IP address>
     -port <port no. server listens on>
     -LS <db server to save to>
     -LU <username for db being saved to>
     -LP <password for db being saved to>
     -LDB <db to save to>
 
     Would be desirable to allow the user to configure the following parameters:
     -INCLSQL <SQL Commands to exclude, i.e. ALL except>
     -EXCLSQL <SQL Commands to include, i.e. NONE except>
 
3.0  Must support MS SQL (TDS) for SQL Server 2000
3.1  Would be desirable to support Oracle SQL*Net (TNS)
3.2  Would be desirable to support MySQL
3.3  Would be desirable to support Sybase
3.4  Would be desirable to support DB2
3.5  Would be desirable to support Teradata