summaryrefslogtreecommitdiff
path: root/src/transport/gnunet-service-tng.c
diff options
context:
space:
mode:
authorChristian Grothoff <christian@grothoff.org>2019-10-31 13:03:48 +0100
committerChristian Grothoff <christian@grothoff.org>2019-10-31 13:03:48 +0100
commit7e3cf5f461eb4fbb7581672bf0835da07c378136 (patch)
treebdc3874b7894242b095b892f1ed3e81a4d4f06c0 /src/transport/gnunet-service-tng.c
parent01b480d6d026e0c537dc284a7e7df2c0320a3528 (diff)
tighten formatting rules
Diffstat (limited to 'src/transport/gnunet-service-tng.c')
-rw-r--r--src/transport/gnunet-service-tng.c15
1 files changed, 5 insertions, 10 deletions
diff --git a/src/transport/gnunet-service-tng.c b/src/transport/gnunet-service-tng.c
index 66a836b84..8d68d90a6 100644
--- a/src/transport/gnunet-service-tng.c
+++ b/src/transport/gnunet-service-tng.c
@@ -4734,8 +4734,7 @@ consider_sending_fc (void *cls)
then. See vl->last_fc_rtt! NOTE: to do this properly, we also
need an estimate for the bandwidth-delay-product for the entire
VL, as that determines "significantly". We have the delay, but
- the bandwidth statistics need to be added for the VL!*/
- (void) duration;
+ the bandwidth statistics need to be added for the VL!*/(void) duration;
GNUNET_log (GNUNET_ERROR_TYPE_DEBUG,
"Sending FC seq %u to %s with new window %llu\n",
@@ -5218,8 +5217,7 @@ handle_raw_message (void *cls, const struct GNUNET_MessageHeader *mh)
we pass this on, CORE would be confused (link down, messages
arrive). We should investigate more if this happens often,
or in a persistent manner, and possibly do "something" about
- it. Thus logging as error for now. */
- GNUNET_break_op (0);
+ it. Thus logging as error for now. */GNUNET_break_op (0);
GNUNET_STATISTICS_update (GST_stats,
"# CORE messages droped (virtual link still down)",
1,
@@ -8643,8 +8641,7 @@ select_best_pending_from_link (struct PendingMessageScoreContext *sc,
given message fits _this_ queue, and do not consider how well other
queues might suit the message. Taking other queues into consideration
may further improve the result, but could also be expensive
- in terms of CPU time. */
- long long sc_score = sc->frag * 40 + sc->relb * 20 + sc->real_overhead;
+ in terms of CPU time. */long long sc_score = sc->frag * 40 + sc->relb * 20 + sc->real_overhead;
long long pm_score = frag * 40 + relb * 20 + real_overhead;
long long time_delta =
(sc->best->next_attempt.abs_value_us - pos->next_attempt.abs_value_us)
@@ -8848,8 +8845,7 @@ transmit_on_queue (void *cls)
via DV (and thus the ultimate target of the pending message is for
a different virtual link than the one of the queue), then we need
to use up not only the window of the direct link but also the
- flow control window for the DV link! */
- pm->vl->outbound_fc_window_size_used += pm->bytes_msg;
+ flow control window for the DV link! */pm->vl->outbound_fc_window_size_used += pm->bytes_msg;
if (pm->vl != queue->neighbour->vl)
{
@@ -8888,8 +8884,7 @@ transmit_on_queue (void *cls)
OPTIMIZE: Note that in the future this heuristic should likely
be improved further (measure RTT stability, consider message
- urgency and size when delaying ACKs, etc.) */
- update_pm_next_attempt (pm,
+ urgency and size when delaying ACKs, etc.) */update_pm_next_attempt (pm,
GNUNET_TIME_relative_to_absolute (
GNUNET_TIME_relative_multiply (queue->pd.aged_rtt,
4)));