On Wed, Aug 12, 2009 at 10:11:30PM +0200, Michael Sprauer wrote:
in stdint.h. When we ask for a uint32_t we want an unsigned 32-bit
integer. We don’t care what it’s called. We care very much about its
size, since it’s part of the specification of the on-the-wire format.
I’m pretty sure I didn’t get the point of this typedefs. But my gcc compiler
didn’t grasp it either. But unsigned int and unsigned long are both 4bytes, at
least on my Win32 XP-System so maybe it’s not to wired. Maybe I find some time
to track it down once I finished the other parts.
It’s OK that unsigned int and unsigned long are both 4 bytes int.
On many (most?) 64-bit machines running 64-bit OS’s int is 32-bit and
long is 64-bits. If we wanted 64-bits we would have used int64_t
Today a had the “first contact” with the USRP2 via ethernet. But I realized,
that I’d have to rewrite major parts of the memory handling in the receiving
part as kernel buffer is not supported by pcap. I’d suggest to rewrite it
completely so that the linux part is also using the pcap-lib for better code
What is your opinion?
Part of the problem with pcap is that you never know what it’s doing
behind the scenes. The way we’ve written the current code, we know
what’s going on, and are pretty sure there’s no faster way to get
packets out, including jumbos if we wanted them too.
I should be possible to have the pcap version exist in parallel in the
When we move to UDP, I don’t think we’ll need pcap.