[Winpcap-users] RE: TCP/IP stack - reinventing the wheel

Wed Aug 16 22:30:03 GMT 2006

Mark

At the very bottom here you mention using uIP.  But since uIP is really
for embedded systems, or simple devices, how are you using it for your app?

I also believe it only supports one device (wire level), which leaves
multiple instances of uIP of course to do real world work...

You mention passing very large arrays with packet data.  I am having a
thought of bypassing any possible problems with passing arrays -- as in
using multiple high level languages to actually use the data.  Not all
high level stuff is array parameter friendly (IMO).  I have given
serious though of packaging data in XML and passing in some type of
buffer of char parameter, whatever.  Main reason is many languages now
support XML stuff so there should be a lot of internal support on the
higher languages for deciphering the XML data.

Anyway, I am looking hard at it.  I hate XML because of XML "bloat" but
it may remain a necessary evil.  As it is easier for humans or higher
level stuff to read & process.

I still have a a number of little "things" to do before I go there.  I
am doing a proof of concept that is doing all the tough stuff to prove
it can be done at a reasonable cost in a mad scientist lab.  Then tackle
an actual implementation once that is conquered.

Thanks,
~ Thomas O'Hare ~
President, RedTile, Inc. - DBA: RedTile Software
Web, Wireless, Network, Database & Systems Software
+1.407.295.9148 ; +49.8651.717950 ; http://www.RedTile.Com/
Operations Manager; Virtual FoxPro User Group
Tom at VFUG.Org ; http://www.VFUG.Org/

Mark Buchanan wrote:
> Thanks for your responses:
> 
>> From: "Ramiro Polla" <ramiro86 at hotmail.com>
> 
>> Hello Mark,
> 
>> Try uIP. It's very nice, and it has a windows port.
> 
>> www.sics.se/~adam/uip/
> 
>> Bye,
>> Ramiro Polla
> 
> Ramiro,
> 
> I have looked at this site and it looks promising. There are some
> concerns however: The code basically is for porting the TCP/IP stack to
> small devices. What I need to do is add on to the TCP/IP stack so that
> the application can pretend to listen on and accept connections for
> multiple IP addresses (not listening for multiple connections from
> multiple IP clients but pretending to be multiple servers at the same
> time). I don't know if I have the expertise to use the C code from this
> site, port it to a Windows environment (preferably VB.NET), and make the
> necessary extensions needed. * * * See more comments below.
> 
> - - - - 
> 
>>> From: "Thomas O'Hare" <Tom at RedTile.Com>
> 
>>> Mark
> 
>>> A question first.
> 
>>> When you did your DLL did you create your own functions?  If so, did
> you put them into a type of library to define them?  If so, what type of
> library and what else can you share on this.  My biggest problem is my
> own functions to be exported for use by "other" programs.  IOW, I need
> to write functions to simplify a lot of what goes on in WinPCap so the
> higher language (with less inherent power) can more easily process data.
> 
>>> Maybe an Answer:
> 
>>> Not really, but it is worth mentioning.
> 
>>> Can you set up a subnet mask to filter the IP addresses you want
> monitored?  It is usually much easier at some point in your code to
> define a subnet if possible as a filter then process the IP's that are
> filtered.
> 
>>> Thanks,
>>> ~ Thomas O'Hare ~
>>> President, RedTile, Inc. - DBA: RedTile Software
>>> Web, Wireless, Network, Database & Systems Software
>>> +1.407.295.9148 ; +49.8651.717950 ; http://www.RedTile.Com/
>>> Operations Manager; Virtual FoxPro User Group
>>> Tom at VFUG.Org ; http://www.VFUG.Org/
> 
> Thomas,
> 
> The DLL that I wrote is extremely small. Most of the code comes right
> out of the WinPCAP examples - with a few things added for my own
> customization. There are 4 functions defined that the VB.NET application
> calls: one to select an adapter - defined by number, another to close
> it, another to process incoming packets (the DLL receives the packets as
> they come in and stores the packet data into a large array, when the
> function is called the entire array is passed to VB and the DLL array is
> reset), and the last to send out a single packet. It would have made
> more sense to have a callback function defined for incoming packets but
> this wasn't necessary - the incoming packets also came in bursts with up
> to 20 packets coming in within 2 ms.
> 
> Note that I don't bother with anything but the packet data itself. The
> time stamp, header info, MACs, etcetera is ignored. In this application
> the VB.NET handles all protocol issues including timing and resending of
> packets as needed - it's a good thing that it is simple protocol and I
> have had a few years to master it. TCP/IP seems a little overwhelming at
> this point.
> 
> I actually purchased a commercial DLL that does what's needed before I
> wrote my own. (There is a link on the WinPCAP FAQ site to this
> software.) The purchased DLL solution proved to have serious performance
> issues (it could handle about 600 packets / second but killed CPU usage
> - I needed to handle 2000 packets / second). I also tried a solution
> that made direct calls to the adapter using C# - doing a simple
> performance test showed that this was also way to slow. The DLL that I
> wrote myself works extremely fast - so much so that I had to slow down
> the sending of data packets because the software receiving and
> processing them on separate PCs couldn't handle it.
> 
> I don't mind sharing the DLL code that I wrote - let me know.
> 
> - - - - 
> 
>>>> Ramiro
> 
>>>> Sounds nerdy enough for me to get happy about.  But it says for 8 or
> 16 bit controllers.  IOW, I get the feeling it is for embedded or
> proprietary hardware.
> 
>>>> I think Mark needed at least 32 bit stuff.
> 
>>>> Am I missing something?
> 
>>>> Thanks,
>>>> ~ Thomas O'Hare ~
> 
> ------------------------------
> 
>>>> Hello,
> 
>>>> It is meant for embedded hardware. But it does communicate well with
> any 
> other TCP/IP stack.
> 
>>>> The code is very generic and simple (always uses 8-bit bytes, no
> words or 
> dwords) so that it will compile on most non-C-compliant proprietary 
> compilers. Gcc optimizes it very well. It does a good job on finding out
> 
> what could be 32-bit and making it good for the processor.
> 
>>>> I`d say It`s worth the try.
> 
>>>> Ramiro Polla
> 
> I have downloaded the source code and have started to look at it. One
> strategy might be the following:
> 
> 1. Take the uip code and encapsulate it in an object in .NET or a DLL.
> When the object is created give it an IP and MAC address.
> 2. Use WinPCAP to capture all packets, filter the packets sending them
> to the appropriate uip object.
> 3. When uip sends out packets they get routed through to WinPCAP again.
> 4. Provide an interface to the higher level application to handle data
> IO.
> 
> For me these tasks do present a large challenge - might even look at
> outsourcing this part.
> 
> Mark
> --------------------------------------------------------
> 
>  
> Mark Buchanan
> 
> 
> Senior Engineer, Controls Systems
> Giffels Associates Limited
> 
> 
>  
> Mark.Buchanan at giffels.com |  T 416 675 9750 Ext. 5253  |  F 416 798 5559  |  giffels.com
>  
> 
>     This communication is intended solely for the addressee(s) and contains information that is privileged, confidential
>     and subject to copyright. Any unauthorized use, copying, review or disclosure is prohibited. If received in error,
>     please notify us immediately by return e-mail.
>  
> 
> --------------------------------------------------------
> 
> _______________________________________________
> Winpcap-users mailing list
> Winpcap-users at winpcap.org
> https://www.winpcap.org/mailman/listinfo/winpcap-users