> You're using network_data[] array to store layer-specific data. If I > understand well, network_data constains all the bits you'll finally send > over serial or any other physical media. Reading (quickly) the code, you're > filling this array, using an offset variable: when you're in ICMP (app > layer), network_var_offset matches the correct index within the array > (though it can be hard to follow as the network_var_offset is modified by > everybody everywhere, but anyway...).
Yes, that's correct. Each underlying protocol will modify network_var_offset so the next protocol doesn't have to. Notice that UDP and ICMP libs do not modify network_var_offset. Any new protocol using IP will not need to modify network_var_offset, but will need to use it to calculate packet data size. in icmp_send_echo_reply() -- send the packet network_send_packet(network_var_offset + message_size) Although, I could move "network_var_offset + " into network_send_packet(). Then the ICMP/UDP libs would only need to specify the size of it's self. > So, back to our API thoughts... Let's consider icmp_send_echo_reply() > procedure. What I, the callee, would want to do when having to send a reply, > is to fill my part on network_data, and maybe set one or more flags > specifying current involved protocol is me (ICMP), then call the underlying > layer and let it does its job. What I do *not* want to is to deal with some > details I shouldn't be aware of, like knowing if ethernet is involved. My > contract is to forge the ICMP reply, that's all, and, well, that's quite a > job isn't ? :) As suggested previously, I will moved this Ethernet check into IP lib and MAC libs. ICMP and UDP should not have to deal with something 2 layers down. I think I fixed your issue, but in another way. I'll upload my new code soon so you can have a look. IP is the lowest level protocol if MAC is not used, so It will need to do this check. I could have IP check if MAC lib is defined, or if "const NETWORK_USE_MAC == TRUE", but the user should not need to deal with setting this constant. Another suggestion.. maybe I could check if a mac address is defined, if so, use MAC. in network_globals (device setup/aliases), for ENC28J60 Alias NETWORK_LOCAL_MAC is ENC_LOCAL_MAC and in IP lib: if defined(NETWORK_LOCAL_MAC) -- call MAC library What do you think? > I hope you're still there, and if so, I hope you understand what I mean. You > actually have this kind of encapsulation, partly: you're filling > network_data[] in ICMP, except ethernet frame (but also deal with IP), then > let network_send_packet() deal with datalink stuff. What I'm suggesting is > to move this encapsulation scheme to the end, that is, dividing/splittting > actions by layers. Again these are very rough thoughts, it may not be > practical... > > I can see at least two main problems: > > - offset: my approach assume that, going up-to-down, you're able to know > the proper offset, matching corresponding data within network_data array. > Basically, your approach is to fill bottom-up, that is, from the beginning > of the array, to the end (except ethernet). This offset may be computed and > derived as you go upper, and may be hard to compute or guess the other way. I don't see why it matters if I go bottom up or top down approach. You can still have encapsulation. I find "for using" is more readable when counting up. Knowing offset would just be a matter of knowing the size of the data. Again, everything would modify the offset, except the high layer. We'll get the same result. UDP/ICMP would deal with IP only IP would need to do a check if Ethernet is used, if not deal with MAC. > I'm not sure yet if this is the proper way to go. Implementing different > application layer protocols will help understand if it is or not... > > HTH > Cheers, > Seb Thanks Seb, please don't give up on me if I still don't understand the poiint :) Matt. -- You received this message because you are subscribed to the Google Groups "jallib" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jallib?hl=en.
