PDA

View Full Version : Packet Driver interface code for Turbo C++ 3.0



mbbrutman
October 11th, 2008, 08:14 PM
I have added some comments to my packet driver interface code and created a small sample program to demonstrate how to use it. If you are interested in playing with packet drivers but were daunted by the packet driver specification, this should get you started.

The zip file can be found here: http://brutman.com/Dos_Networking/mTCP.html . Look for 'tcpacket.zip' in the download section.

This should be fairly portable to other versions of C. Also, don't feel that you need to master TCP/IP to use this - you can send *any* packet type you want. Experiment and make your own lightweight protocols!


Mike

Mike Chambers
October 11th, 2008, 08:36 PM
excellent! i'm going to play with this. is mTCP code ready? i don't care what state it's in. :P

can i get maybe a special advance private copy? :D:D

mbbrutman
October 12th, 2008, 06:12 AM
I am not releasing source code for anything else anytime soon. I will share snippets where it makes sense, but not the whole project. Like I have said before, it is not ready. (Although I am feeling quite good about it after the last test I ran.)

This thread is for announcing the availability of the sample code to drive a packet driver in C. It should be easily ported to other C variants, or if somebody wants to do a little more work Pascal should be possible.

Besides the actual calls to the packet driver interface, the slightly tricky code to handle incoming packets asynchronously is there too. This code allocates room for twenty max-sized Ethernet packets (1514 bytes including the Ethernet frame header) and then uses a simple stack to manage the free buffers and a ring buffer to manage buffers that have been filled by the packet driver but not yet picked up and processed by the user code.

The code is very fast. The stack gives a quick way to see if a buffer is available for an incoming packet. The ring buffer keeps the incoming packets that have been accepted in order until the user processes them. The user has the option to 'hold onto' pointers to buffers for processing, and then put those buffers back into the free stack after they are done processing. This allows for the user to process an incoming packet without an expensive memory copy to copy the contents into their own buffer.

In my code at the TCP layer I do a memcopy into a user defined buffer. I've found that it is slower, but I put a higher priority on getting the incoming packet buffers back to the free list. For telnet-like traffic where there are lots of little packets this makes more sense rather than letting the end user hold the incoming buffer directly for long periods of time.

(UDP still does it the first way - the user processes the incoming packet directly.)

Also, note the complete absense of locks or mutexes. I have to disable interrupts for short periods of time when manipulating the ring buffer or free list, but that is about it. These data structures are shared between the packet driver and user code, so disabling the interrupts is required when in user space to prevent the packet driver from interrupting, trying to get a buffer, and catching something 'in between'. There might be a quicker way to do this by taking advantage of atomic operations, but this is good enough.

Anyway, that is some of the design philosophy of this code. I am sure that somebody can come up with something slightly more clever than can either improve performance or reduce memory consumption.

ziloo
October 22nd, 2008, 06:53 AM
Hello Mike,

Can you put together a simple write up as to how to connect two computers and
use your code to accomplish sending a small file from one to another? I am very
interested, but I don't have all the background needed to implement your marvellous
program.

Thank you

ziloo

mbbrutman
October 24th, 2008, 05:29 AM
Ziloo,

I'll put something together and post it somewhere. This probably isn't the right thread as it's more for people who want to start experimenting with packet drivers in C, but a tutorial wouldn't be bad.

It also might be more appropriate to talk about FTP too. My version of netcat (as well as WiWa's) can move files, but it really is so much easier with NCSA telnet because it has an FTP server built in.


Mike

joelpietersen
January 30th, 2009, 03:01 AM
Thanks for this. I am going to try this as soon as I get home!