Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
soc:nikhilcrao [2006/06/16 03:09] nikhilcrao |
soc:nikhilcrao [2006/07/17 21:13] (current) nikhilcrao |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| ====== Nikhil Rao, Implementing IPv6 support in gPXE ====== | ====== Nikhil Rao, Implementing IPv6 support in gPXE ====== | ||
| + | |||
| + | |||
| + | //Quicklink: [[revised timeline|Timeline]]// | ||
| ===== About the project ===== | ===== About the project ===== | ||
| My project is titled Implementing IPv6 support in gPXE. Here are some snippets from [[soc:nikhil:proposal|my proposal]]. | My project is titled Implementing IPv6 support in gPXE. Here are some snippets from [[soc:nikhil:proposal|my proposal]]. | ||
| - | [[revised timeline]] | ||
| ==== Synopsis ==== | ==== Synopsis ==== | ||
| Line 47: | Line 49: | ||
| I have tried to update my blog as frequently as possible with my thoughts. Here are some important notes which have been edited after IRC conversations, e-mails and IM sessions with Michael and Marty. | I have tried to update my blog as frequently as possible with my thoughts. Here are some important notes which have been edited after IRC conversations, e-mails and IM sessions with Michael and Marty. | ||
| + | |||
| + | ==== Implementing TCP ==== | ||
| ==== gPXE network infrastructure ==== | ==== gPXE network infrastructure ==== | ||
| Line 428: | Line 432: | ||
| TCP would require a much more complicated ''trans_protocol->rx_process()'' function which would check the state of the TCP connection and proceed accordingly. | TCP would require a much more complicated ''trans_protocol->rx_process()'' function which would check the state of the TCP connection and proceed accordingly. | ||
| + | |||
| Line 486: | Line 491: | ||
| When the ''IP_FRAG_FIN'' flag is set, the packet is sent to the transport layer protocol for processing. The ''reass_buffer'' is discarded and memory is released. | When the ''IP_FRAG_FIN'' flag is set, the packet is sent to the transport layer protocol for processing. The ''reass_buffer'' is discarded and memory is released. | ||
| + | ==== More on IP fragment reassembly ==== | ||
| + | |||
| + | Last night, Michael and I had a long IM session in which we discussed the reassembly requirements. Here are the main points: | ||
| + | |||
| + | - We assume that the fragments are received in order. We do not need to remember where in the original packet the recived fragment fits. This greatly simplifies the process of reassembling fragments. | ||
| + | - If a fragment is received out of order, we simply assume that the missing fragment (before it) is lost and we discard the reassembly buffer. | ||
| + | - If the offset field of a fragment is equal to 0, then we create a new reassembly buffer for the fragment series as described in the earlier note. | ||
| + | - If the offset field if not set, we identify the fragment series. If the offset + total_length of the last received fragment in the fragment series is equal to the offset of the received fragment, we add the fragment to the fragment series. Else we discard the fragment series. | ||
| + | - If the more fragments field is not set, i.e. this is the last fragment of the series, on successfully adding the fragment, we invoke the transport layer's ''rx_proces()'' function and pass the reassembled buffer into it. | ||
| + | - We need to write ''realloc_pkb()'' which will take a packet buffer and a new length, allocate a new packet buffer for the new length, copy the contents of the old packet buffer into the new one, and then free up the old packet buffer. This function will be useful in maintaining the reassembled buffer. | ||
| + | |||
| + | (I apologise for the verbose and hasty notes. I will compile a more elaborate one with code snippets soon) | ||
| ==== To do list ==== | ==== To do list ==== | ||
