Pongs from multi servers in multicast with underload & pingpong

[GoogleCodeExporter]

imported from: http://argus-bg.dnsalias.org/issues/716

What need is this feature going to satisfy?
1.
The feature is needed in case there is one client that send MC packets to N 
servers, all of them are expected to respond. We need to manage the replies and 
know which reply came from which server. Suggestion: add server-id to the 
header, this can be instead of the C/S bit (client will use zero in this 
field). Need to decide how to assign ids to servers, perhaps use long enough 
random number.

Anyhow,
PacketTimes array is already designed to accept MC pongs from multiple servers.
Also the statistics at the end already designed to print results for each 
server separately.
The only needed thing in the client is to recognize from each server came each 
packet and put the rxTime of the packet in the appropriate column of 
PacketTimes array.

2.
This is one of the last feature that older VTG (I think thats was its name) 
used to have which vperf still does not include.

PS: Another design possibility, instead of server id, might be to you the 
recvfrom(from_addr) to map the replies into the results table.

Original issue reported on code.google.com by igor.ivanov@itseez.com on 1 Apr 2011 at 1:58

[GoogleCodeExporter]

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.

Original comment by avne...@gmail.com on 3 Apr 2011 at 8:25

• Changed state: Accepted
• Added labels: Branch-1.x, Priority-High
• Removed labels: Branch-2.x, Priority-Medium

[GoogleCodeExporter]

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);

Original comment by igor.ivanov@itseez.com on 15 Apr 2011 at 3:00

• Changed state: Started

[GoogleCodeExporter]

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.

Original comment by igor.ivanov@itseez.com on 20 Apr 2011 at 8:12

[GoogleCodeExporter]

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)

Original comment by avne...@gmail.com on 27 Apr 2011 at 9:55

[GoogleCodeExporter]

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.

Original comment by igor.ivanov@itseez.com on 13 May 2011 at 6:36

• Changed state: Fixed