Hi Sushil
The ARP frames which you are seeing are normal. They are automatically handled by the protocol layers and so are invisible to the user. If using RAW TCP socket your listner will however receive a "regenerate" event [TCP_EVENT_REGENERATE] if the TCP frame could not be sent immediately - this will be take place once the ARP process has resolved the MAC address of the destination IP address.
If you are using a buffered TCP socket also the regeneration will take place automatically.
Basically the ARP process will not affect reception. During the ARP resolve period no more TCP frames can be sent the the socket in question but any other sockets are not affected - there can at any point of time be multiple ARP resolution processes in progress.
However I have just retrieved the Ethereal recordings that Kumar posted and have seen that the network activity that you have is not as expected and possibly represents something "abnormal". I have seen that in the recording "28_03_07_1" there are two devices at addresses 192.168.1.170 and 192.168.1.171. 170 is generally sending a frame once every 10s or so. I see (almost) no other activity on the network but this may be due to switches and/or Ethereal filtering.
The first thing that surprises me is that sometimes one of the devices (are they PCs or embedded devices? are they board or uTasker simulators?) sends an ARP although there is constant network activity. The ARP table has place for ARP_TABLE_ENTRIES (8 in the standard configuration) which can be modified in config.h and these entries remain in the table until they have no longer been 'seen' on the network for a period of 20 minutes. Each time 'seen',the entry will be refreshed.
If there is an ARP request taking place it can be because there are a larger number of devices than there are ARP entry spaces and so the oldest one will get dropped when a new one has to be entered (this is not visible but may be the cause). Therefore ARP requests could be normal and as such don't automatically show a problem. Since that are generally resolved immediately there is no impact on the system. (See lines 99 in the recording)
In the recording there is however a problem at line 217. Here IP 170 seems to have been reset because it is sending an ARP to establish the 'same' TCP connection again. This is denied and the connection closed before a second attempt establishes a new connection (line 222). Again it looks as though IP 170 was reset again because it start with an ARP although it would normally not need to resolve.
At line 500 a third device (IP 16) connects to 171 via FTP and loads a couple of web pages.
At line 820 IP 1 - probably a PC with Mozilla based Browser connects to the web server.
from line 1574 there are various further ARP requests which get answered but don't seem to be received by IP 171. The connection eventually breaks down and so represents some problem.
I suggest the following:
1. I see that you are running project V1.2.007 - there is a patch in driver.c due to a LAN reception problem which could occur after several days or weeks of operation (perhaps your network is suited to seeing it faster?). I will send this patch with explanation to Kumar's email address.
2. The present V1.3 is worth using since it has quite a number of interesting new features and includes all bug fixes to date. If you would like to receive this (it has an imporved simulator which helps to save more development time) just send me a mail. Apart from the project configuration, which has been imporved to maintain parallel projects on different boards, your application should remain compatible.
Regards
Mark
www.uTasker.com