Tendency : A KDevelop plugin for testing Network Applications, proposal for GSoC

[Rohan Prabhu]

Hey all,
I would like to have your attention for a minute so as to present a proposal
for a KDevelop plugin called 'Tendency', as my GSoC project proposal, the
aim of which was to ease the development of networking applications and to
provide a rigorous testing framework for the same. I waited a little time
for some rustling on the kde-soc mailing list, but none happened, so
tonight, I sat to develop a small mock GUI for the same, which would better
help me explain what I want to do with this application.

Idea: I basically want to create a system which can send data over the
network to an application which is being tested. Let's take the case where I
am a developer who is making a small QOTD [Quote of the Day] server, which
runs on HTTP. I make the server using, let's say the Qt framework. Now,
using tendency, I can automate the process of sending requests to the server
and receiving their response and analyzing their response.

Links to a screenshot of the mock-up of the application:

http://i40.tinypic.com/v5k3kw.png

How it works: Please refer to the screenshot I've provided in the links
above. Firstly, I select the 'HTTP' from the list of protocols. Each
protocol that I select has it's own 'Datagram Editor' as you can see for
HTTP below. Then, I select if I want to send the data over the network to an
external address. If unselected, the data is sent over the loopback address
[or the localhost]. One can also select the port the data is to be
transmitted on. The third option which says, 'Transmit data after [2]
seconds of starting debugging', is basically to auto-trigger the sending of
data. A small delay is provided for the server to be setup and running. One
can also uncheck it and transmit the data manually if she/he prefers. Next,
I can select the sending method of the data [POST or GET] and then change
the variables of POST and GET. The 'Variable Editor' opens a small dialog
with which one can edit the various variables. The next option is to send
any files if needed over POST. Thirdly, we can edit the body of the HTTP
request directly. One can use it to not only test servers, but also clients.
And, in the final section, one can edit the headers of the HTTP message.

What I propose further:
1. A framework to automate these tests and to provide a way to write unit
tests for the same.
2. A system to analyze the response of the sent request, or to listen on a
port for sometime and analyze the received data.
3. A proper header editor, where one can edit the headers properly. By
proper, I mean that for a header like 'Date', one can select a date from the
calendar.
4. For TCP/IP and UDP [or Raw] network data, the following framework is
proposed by me:

Raw network data can be thought to be made up of fields. In tendency, the
Datagram editor for TCP/IP and UDP shows a list of fields. For example, in a
custom implemented protocols, one may have the fields:

a. A [size] field: Specifying the size of the entire message.
b. A [magic_numbers] field: Push in some magic numbers required by the
protocol
c. A [custom_data] field: A field of binary data
d. A [metastring_size] field: A field specifying the size of the succeeding
metastring_size
e. A [metastring] field: A final string for some purpose.
f. A [checksum] feld: An md5 checksum of the entire datagram.

In the Datagram editor, the fields are shown as rectangles, and double
clicking any of the rectangles opens up a dialog where one can select from
the following options:

1. size : Size of the field
2. contents : Contents of the field

Although pretty straight-forward, tendency aims to make this process as
comprehensive as possible. Tendency uses a concept of 'filters' to modify
data present on other mediums, like the hard disk for example. Using this
dialog, one could set the following options for the above mentioned fields:

a. [size]: size: 4 bytes
           contents: sizeof(__datagram)
b. [magic_numbers]: size: 6 bytes
                    contents: 0xBF 0xF4 0x56 0x7C
c. [custom_data]: size: /dynamic/
                  contents: fromfile('/usr/bin/a.out')
d. [metastring_size]: size: 4 bytes
                      contents: sizeof(metastring)
e. [metastring]: size: /dynamic/
                 contents: '--//x-metastring-broadcast//--'
f. [checksum]: size: 32 bytes
               contents: md5(fieldRange(size, metastring))

In the above example, some fields were pure constants, whereas some fields
depend on other fields for their content. I have tried to give as many
examples as possible. If you so wish, I would love to provide you with more
details. Please give me your comments and any suggestions that you may have.
I shall await your reply.

Regards,
Rohan Prabhu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20100328/cea33cd6/attachment.html>