[WLANware] SNMP plugin for OSLR - GSoC 2011

ambarisha b b.ambarisha at gmail.com
Wed Mar 30 01:09:30 CEST 2011


Hi Marek,

On Tue, Mar 29, 2011 at 5:46 PM, Marek Lindner <lindner_marek at yahoo.de> wrote:

> there is no other UDP consumer it won't make much of a difference. We can still
> split the functions as soon as we have one.

That is fine then.One other case I could think of was when we want to
process the packet again somewhere else.If it were a function then we
could call it separately.Still that's just a hypothetical case.I guess
you are right, may be I was affected by my personal taste.

> I went over the code but could not see how this translates into a problem. Can
> you be more precise which variable is updated too soon / should be "cleaned
> up" ?

Whenever we send a packet we are updating
node->image_state.last_packet_size and node->image_state.bytes_sent,
if we recieve an ack that doesn't correspond to the last sent block,
we are reducing the node->image_state.bytes_sent back.Suppose,we
increase the node->image_state.bytes_sent and set the
node->image_state.last_packet_size, then go into the
tftp_packet_send_data().That function returned a '-1' , may be because
there was an error while writing to the raw socket.Then shouldn't we
clean up the bytes_sent and last_packet_size because the transmission
hasn't really been done.Please explain this issue, because I am not
sure I am seeing the entire picture.

> The idea was to keep it simple. However, I don't understand why you would want
> to have another variable called raw_sock in ap51-flash or link arbitrary files
> with other files.
> But you easily could "solve" this by declaring raw_sock "static".

We were talking about the code being generic.So, I just wanted to
point out that one could not use the socket code for general purpose
i.e it wasn't generic.What I didn't notice was that raw_sock wasn't
being used in any other file, so a simple "static" would fix this.

One more thing, suppose for some reason the router went down suddenly
in the middle of a transmission ,we wouldn't have any way to identify
this situation and quit with an error, right ? The only way I can see
is to have a timer that is set between each transmission and
ack-recieving.What do you say?

Really appreciate your time and patience with this.

Cheers
Ambarish



More information about the WLANware mailing list