Pongs from multi servers in multicast with underload & pingpong about sockperf HOT 5 CLOSED

1. As agreed, no need to change the protocol with additional server-id field
2. we'll use the from_address of the packet to map the packet to the right peer.
3. This can be done, based on the gap analysis feature in the server, that uses 
hash table to map packet to the right peer.
4. As said, the PacketTimes array (and the statistics at the end), are already 
written (by me) with this mode in mind.
5. This feature should be 1st implemented for sockperf_v1 and only after it is 
completed to be merged into sockperf_v2.
6. Igor, please specify your design/plan and then assign my the issue for 
approval.  Don't start coding before I see the plan.

Requirements to be clarified:
1. Is there limitation to number of servers;
2. Should a client and all servers use the same multicast group for 
send/recieve operations;
3. What way should be used on client side for ping-pong mode (wait for answers 
from all servers, etc);

Design in assumptions:
- Do not care about number of servers (note: system limitations related amount 
of memory can raise error);
- Use the same multicast group for send/recieve on server/client (note: VTG 
defines specific sockets for recieving);
- Client waits for reply-packets from number of servers defined in commad-line;

Plan:
1. add servers list array in ClientBase class; This array is filled in 
accordance with order of getting reply-packets from unique addresses;
2. implement client_get_server_id() method for Client class returning server No 
by recieved address. Function should return -1 in case address is not found in 
servers list array;
3. call client_get_server_id() to define server No before saving Rx time. 
Recieved reply-packet is ignored in case returned value is -1;
4. in ping-pong mode client send next packet in case accepted all reply-packets 
from number of servers defined in option --srv-num.

1. I think we would like to support "big" number of members in the multicast 
group (say tens or hundreds); hence, I would recommend using the code we 
already have in the server for gap analysis feature.  This hash maps the peer 
address to the right peer number.  In the fast path it is better to use this 
way than to scan entire array.

2. In ping-pong mode the client must wait for all expected pongs before sending 
next ping.  In under-load, there shouldn't be big changes.

3. Please consult AlexR whether to use same MC group for send & receive or to 
behave like VTG?

4.  In case reply packets match more then --srv-num peers you can abort.

5. Please assign me back the issue after you have answers for all points 
(before starting to code)

r54
This ability is enclosed in EXTRA_ABILITY macro definition. It is disabled in 
build process by default. User needs to set --enable-extra option in configure 
as ($ ./configure --prefix=<path to install> --enable-extra) to make 
functionality workable.

Note: Implemented approach using the same multicast group for send/recieve on 
server/client.