Re: embedded tcp input only optimizations

For my application only tcp input is required. This should eliminate
the need to maintain timers

Hmmm, depends who is initiating the connection, but either way with
todays syn flood prevention algorithms in place (syn cookies) I think
you will not get away without retransmitting either the initial SYN or
the SYN/ACK if the need arises.

and thus allow for a purely interrupt
driven implimentation (i.e. no real-time OS).

Um, I don't see why you should not be able to also generate an
interupt based on the timer and deal there with segment
retransmission. Since this happens only ocasionally anyways, I don't
think that the penatly would be that noticeable.

If possible I would like to design the interrupt handler such that it
pulls packets out of the NIC (RTL8019AS), and simultaneously:

1. Checksums the payload for a final ACK/NAK decision
2. parses the incoming data translating control codes into function
pointers and placing these (or the non-control code data) into the
main-loop's receive buffer

Sounds good to me. Consider writing this function in assembly cause
the main performance gain will come from the fact that you load a word
of data from the controller to the CPU exactly only once, and at the
same time summarize it in a CPU register, then store it in your buffer
you intend to pass to the main loop. If you code that in C (on the H8)
I bet that data will be stored on the stak which obviousely will need
much more cycles. Then don't forget that also your answering segments
must have a propper checksum. You could prepare a default segment for
it and only modify the otherwise precalculated checksum with the
changes you do.

By doing these two tasks simultaneously, the main-loop can be
constructed by simply casting the receive buffer's head into a function
pointer and then calling that function.

Does such an implimentation sound possible, and if so, how effective
might it be in increasing device performance.

Sure.

Are any other optimizations possible?

IMHO it depends on what you intend to optimize. If it's the pure TCP
throughput then useing a bigger reciveing window could help at the
cost of a better segment buffering. A very important fact is wether
there are simultanous connections in paralell possible or if your
stack should only deal with one connection at a time. In the latter
case there will be obviousely less overhead involved with buffering.
If you are after optimizing CPU resource useage you will want to have
fewer buffers and rely on the remote end to do more retransmits if
needed etc. You could also consider if you need synflood protection
(asumign you accept incoming connections) or not and also wether you
want to accept early segments or not.

HTH

Markus

.

Relevant Pages

  • Re: [fw-wiz] Post connection SYN
    ... drop the connection request treating it as Post Connection SYN attack. ...
    (Firewall-Wizards)
  • Re: Context of error messages with respect to BSD sockets
    ... under what circumstances will send or recv block? ... A 'connection mode' socket usually has an in-kernel send and ... receive buffer associated with it. ... this signifies that the connection has closed ...
    (comp.unix.programmer)
  • WMP9 Performance tab - Use it, or no?
    ... If I let WMP detect the connection speed, ... the audio plays a half second, breaks for a half second, plays for ... If I extend the buffer out to the max, I do get decent playback, ... Only 2 years ago NASA was using the older format ...
    (microsoft.public.windowsmedia.player)
  • [NEWS] Hardware Defenses against SYN Flooding
    ... Hardware Defenses against SYN Flooding ... The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com ... Establishing a TCP connection requires the exchange of three packets: ... return from the Web server, and finally ACK back from ...
    (Securiteam)
  • Re: help out a boob? whats wrong with this? callback not firing when called recursively
    ... sender has not closed the connection. ... much as all of the rest of the data or the size of your buffer (whichever ... But just as you need to be able to reassemble ... Since reassembling delimiters isn't any different from reassembling the ...
    (microsoft.public.dotnet.languages.csharp)