From willer@wtal.de
Received: by maskin (mbox dlanor)
 (with Cubic Circle's cucipop (v1.31 1998/05/13) Sun May 30 01:46:40 1999)
X-From_: willer@wtal.de Sat May 29 20:06:40 1999
Received: (from uucp@localhost)
	by maskin.ettnet.se (8.9.1a/8.8.8) id UAA01591
	for <dlanor@ettnet.se>; Sat, 29 May 1999 20:06:40 +0200 (MET DST)
From: willer@wtal.de
Received: from UNKNOWN(195.8.224.4), claiming to be "mail.kdt.de"
 via SMTP by maskin, id smtpdAAAa000On; Sat May 29 20:06:33 1999
Received: from [127.0.0.1] (line6.kdt.de [195.8.225.6])
	by mail.kdt.de (8.8.8/8.8.8) with SMTP id UAA06242;
	Sat, 29 May 1999 20:07:38 +0200
Date: Sat, 29 May 1999 20:07:38 +0200
Message-Id: <199905291807.UAA06242@mail.kdt.de>
To: dlanor@ettnet.se (Ulf Ronald Andersson)
Cc: willer@wtal.de
Organization: (none)
Subject: STinG
X-Mailer: SMTP PRIME

Hello Ronald!

I am an expert in C and assembly language programming.
I specialize in high-speed assembly language programming.
I have gathered a lot of experience by producing
multimedia codecs.

Out of curiosity, I have looked into UDP.STX and TCP.STX.

I have done benchmark testing using UDP and TCP feedback
loops on localhost. The feedback loops have been
implemented by the UDP_send() and TCP_send() API calls,
as well as the most critical CNget_char() call.

All testing has been done on a Mega STe 4 at 16MHz
with (and without) cache.

The most defining factor for STinG speed is the "delay"
value set in the "STinG Internals" CPX. Here's why:
Data is only transferred during interrupt. Thus, there
are fixed time slots at which data is transferred. The
above mentioned delay value defines the spacing of these
time slots. The faster the stack works, the higher the
propability of catching earlier time slots. For some
sets of parameters, the total transfer time has been
cut by as much as 50% by reducing STinG API call overhead.

I have completely reworked UDP.STX and large portions
of TCP.STX, particularly the computation of the internet
check sum and the semaphore routines. You may get an
idea of my effort by comparing file sizes:

   UDP.STX v1.42 :     5018 bytes
   My own UDP.STX:     4592 bytes

   TCP.STX v1.14:     10712 bytes
   My own TCP.STX:     9945 bytes

I have also started to add a packet monitoring interface
to TCP.STX which is being used by an ICMP monitoring
accessory. Of course, the IP core would be a better place
to install a packet monitoring interface. I have not yet
looked into STinG itself, though.

Since you have now released a new version of STinG with
different internal structure, I wonder if I should use
that, because I would loose the benefits of my own work.
I haven't really understood what improvements you have
made, apart from the TCP_close. Is the new STinG faster,
more stable, more reentrant? Does it fix any protocol
errors? It would be nice if you could expand on that!

Here are two errors that I noticed:

o The computation of the internet checksum is not
  reentrant. It uses a static variable.
o TCP_close crashes under MiNT/MultiTOS.

Let me know if you would like me to collaborate on
the STinG project. I have had a hard time in the past
because I didn't have any of the sources.

Another thing I would like to see is some facility
to detect port scans and other hostile attacks and to
make STinG immune against such attacks.

Stefan Willer


