Hi Vitaliy, > Too many comments. Ideally, you shouldn't need the comments to understand > what the code is doing: the code itself should be sufficient. With all the respect I do not quite agree with you. Comments are either not for yourself or not for the moment - it is like a paper, helps to remember for things :-) > why not use a structure, instead of an array? Then you could initialize it > like this: > > frame.destinationMac =3D 0x00036f23254a; As far as I understand Tomas (reading all his post back in this list and the current one as well), he would like to write a platform independent code. For this he should make sure that the structure stores all the data stream in the way it should be / in the way it was defined in the standard. On a heterogeneous network the crucial part of any protocol is to have a well defined number representation. I guess that's why it was easier to him to put everything into an array rather than ending up in like: frame.destinationMac =3D LITTLEENDIAN(0x00036f23254a); (where that macro is the one that takes care of the correct endianness) > "Debugging is twice as hard as writing the code in the first place. > Therefore, if you write the code as cleverly as possible, you are, by > definition, not smart enough to debug it." -- Brian Kernighan As far as I know Mr Kernighan said this before the symbolic information and the source level debugging was invented :-) Tamas On Mon, Sep 15, 2008 at 9:54 AM, Vitaliy wrote: > Tom=E1s =D3 h=C9ilidhe wrote: > > Anyone know what's the most portable C networking library to use for > > sending custom frames? By "custom frames", I mean having the ability to > > write the entire frame all by yourself (I think some people use the term > > "raw sockets" to refer to this). For instance, here's a DNS request: > > I don't have enough experience to answer your question, but I do have a f= ew > comments. The first one is that this topic fits better in the [EE] > category. > :) > > > unsigned char frame[] =3D > > { > > /* Offset 0 : Beginning of Ethernet frame */ > > > > 0x00,0x03,0x6f,0x23,0x25,0x4a, /* Destination MAC */ > > 0x00,0x40,0x12,0x1b,0x77,0x36, /* Source MAC */ > > 0x08,0x00, /* Protocol =3D=3D IP */ > > > > /* Offset 14 : Beginning of IP packet */ > > > > 0x45, /* IP Version and header length */ > > 0x00, /* TOS */ > > 0x00,0x3c, /* Total Length */ > > 0x00,0x00, /* Identification */ > > 0x40,0x00, /* Flags and Fragment Offset */ > > 0x40, /* Time To Live */ > > 0x11, /* Transport Layer Protocol =3D=3D UDP */ > > > > 0,0, /* IP Header Checksum */ > > > > 192,168,0,55, /* Source IP */ > > 208,67,222,222, /* Destination IP */ > > > > /* Offset 34 : Beginning of UDP segment */ > > > > 0x80,0x01, /* Source port */ > > 0x00,0x35, /* Destination port */ > > 0x00,0x28, /* Length of UDP segment (header + data) */ > > 0x00,0x00, /* Checksum */ > > > > /* Offset 42 : Beginning of DNS datagram */ > > > > 0x22,0xf4, /* Transaction ID */ > > 0x01,0x00, /* Flags */ > > 0x00,0x01, /* Questions */ > > 0x00,0x00, /* Answer RR's */ > > 0x00,0x00, /* Athority RR's */ > > 0x00,0x00, /* Additional RR's */ > > > > 3,'w','w','w',6,'g','o','o','g','l','e',3,'c','o','m',0, > > > > 0x00,0x01, /* Type A (Host Address) */ > > 0x00,0x01 /* Class IN */ > > }; > > Too many comments. Ideally, you shouldn't need the comments to understand > what the code is doing: the code itself should be sufficient. In this cas= e, > why not use a structure, instead of an array? Then you could initialize it > like this: > > frame.destinationMac =3D 0x00036f23254a; > ... > frame.timeToLive =3D 0x40; > ... > frame.sourcePort =3D 0x8001; > > etc. > > [snip] > > Is there anything better than Berkeley Socket for sending custom frames? > > Anything more portable? Or is there a better way of using Berkeley > > sockets than the way I've shown above? > > The best thing to do is to put code that is likely to change, inside a > custom wrapper. Design the function for sending the raw frame the way *yo= u* > think it should work, and make calls to the library functions from there. > If > you need to switch libraries in the future, you would only need to change > the code in one place (loose coupling). The idea is very similar to the > Adapter design pattern: > > http://en.wikipedia.org/wiki/Adapter_pattern > > Recently I found myself writing wrappers anytime I want to use a Microchip > library function (most of them are horrible, from the POV of readability). > Eventually, I end up refactoring the code until it no longer depends on t= he > library -- but the advantage is that this approach gets me a working > prototype/proof of concept much much sooner (it's also a great starting > point for my own code). > > On another note, it's a terrible idea to use obsure words (or names that > are > too short) as variable names. Don't be afraid to spell them out, err on t= he > side of making a variable name too long, rather than too short. I keep > repeating this quote, which became my motto: > > "Any fool can write code that a computer can understand. Good programmers > write code that humans can understand." -- Martin Fowler > > I also like this quote: > > "Debugging is twice as hard as writing the code in the first place. > Therefore, if you write the code as cleverly as possible, you are, by > definition, not smart enough to debug it." -- Brian Kernighan > > Vitaliy > > -- > http://www.piclist.com PIC/SX FAQ & list archive > View/change your membership options at > http://mailman.mit.edu/mailman/listinfo/piclist > -- = Rudonix DoubleSaver http://www.rudonix.com -- = http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist