Changeset 1010:357c2f892d24 in freeDiameter for libfdcore/p_psm.c

Timestamp:

Mar 26, 2013, 12:39:32 AM (11 years ago)

Author:

Sebastien Decugis <sdecugis@freediameter.net>

Branch:

default

Phase:

public

Message:

Implement a new counter on pending answers to send back to a peer.
Function fd_peer_get_load_pending updated to retrieve this counter as well.
When a peer has answers pending, the connection is not immediately teared down
upon DPR/DPA exchange, but a GRACE_TIMEOUT delay (default 1 sec) is granted.

File:

• libfdcore/p_psm.c (modified) (8 diffs)

libfdcore/p_psm.c

@@ -45 +45 @@
 begining and end of a connection lifetime. It means we need agility to
 switch between "ordering enforced" and "ordering not enforced to counter
-HotLB" modes of operation.
-
-The connection state machine represented in RFC3588 (and rfc3588bis) is
+Head of the Line Blocking" modes of operation.
+
+The connection state machine represented in RFC3588 (and RFC6733) is
 incomplete, because it lacks the SUSPECT state and the 3 DWR/DWA
 exchanges (section 5.1) when the peer recovers from this state.
@@ -91 +91 @@
 application message is lost.
 
-This situation is actually quite possible because DPR/DPA messages are
+This situation is actually happening easily because DPR/DPA messages are
 very short, while application messages can be quite large. Therefore,
 they require much more time to deliver.
@@ -97 +97 @@
 I really cannot see a way to counter this effect by using the ordering
 of the messages, except by applying a timer (state STATE_CLOSING_GRACE).
+This timer can be also useful when we detect that some messages has not 
+yet received an answer on this link, to give time to the application to 
+complete the exchange ongoing.
 
 However, this problem must be balanced with the fact that the message
@@ -197 +200 @@
         return 0;
 }
-static int leave_open_state(struct fd_peer * peer)
+static int leave_open_state(struct fd_peer * peer, int skip_failover)
 {
         /* Remove from active peers list */
@@ -208 +211 @@
         
         /* Failover the messages */
-        fd_peer_failover_msg(peer);
+        if (!skip_failover) {
+                fd_peer_failover_msg(peer);
+        }
         
         return 0;
@@ -288 +293 @@
         
         if (old == STATE_OPEN) {
-                CHECK_FCT( leave_open_state(peer) );
-        }
-        
+                CHECK_FCT( leave_open_state(peer, new_state == STATE_CLOSING_GRACE) );
+        }
+        if (old == STATE_CLOSING_GRACE) {
+                fd_peer_failover_msg(peer);
+        }
+
         if (new_state == STATE_OPEN) {
                 CHECK_FCT( enter_open_state(peer) );
@@ -298 +306 @@
                 /* Purge event list */
                 fd_psm_events_free(peer);
+                
+                /* Reset the counter of pending anwers to send */
+                peer->p_reqin_count = 0;
                 
                 /* If the peer is not persistant, we destroy it */
@@ -529 +540 @@
                                 fd_msg_log( FD_MSG_LOG_TIMING, msg, "Answer received in %d.%06.6d sec.", delay.tv_sec, delay.tv_nsec / 1000 );
                         }
+                } else {
+                        /* Mark the incoming request so that we know we have pending answers for this peer */
+                        CHECK_POSIX_DO( pthread_mutex_lock(&peer->p_state_mtx), goto psm_end  );
+                        peer->p_reqin_count++;
+                        CHECK_POSIX_DO( pthread_mutex_unlock(&peer->p_state_mtx), goto psm_end  );
                 }