CHANGE: fix typo indefenitly=>indefenitely

Author: JohannesKleine

src/gxs/rsgenexchange.cc

@@ -3132,7 +3132,7 @@ void RsGenExchange::processRecvdMessages()
 
             // (cyril) Normally we should discard posts that are older than the sync request. But that causes a problem because
             // 	RsGxsNetService requests posts to sync by chunks of 20. So if the 20 are discarded, they will be re-synced next time, and the sync process
-            // 	will indefinitly loop on the same 20 posts. Since the posts are there already, keeping them is the least problematique way to fix this problem.
+            // 	will indefinitely loop on the same 20 posts. Since the posts are there already, keeping them is the least problematique way to fix this problem.
             //
 			//      uint32_t max_sync_age = ( mNetService != NULL)?( mNetService->getSyncAge(msg->metaData->mGroupId)):RS_GXS_DEFAULT_MSG_REQ_PERIOD;
 			//

src/gxs/rsgxsnetservice.cc

@@ -719,7 +719,7 @@ std::error_condition RsGxsNetService::checkUpdatesFromPeers(
             if(keep_delay > 0 && req_delay > 0 && keep_delay < req_delay)
                 req_delay = keep_delay ;
 
-            // The last post will be set to TS 0 if the req delay is 0, which means "Indefinitly"
+            // The last post will be set to TS 0 if the req delay is 0, which means "Indefinitely"
 
             if(req_delay > 0)
 				msg->createdSinceTS = std::max(0,(int)time(NULL) - req_delay);

src/retroshare/rshistory.h

@@ -153,7 +153,7 @@ class RsHistory
     /*!
      * @brief Sets the maximum number of messages to save
      * @param[in] chat_type Type of chat for that number limit
-     * @param[in] count     Max umber of messages, 0 meaning indefinitly
+     * @param[in] count     Max umber of messages, 0 meaning indefinitely
      */
     virtual void     setSaveCount(uint32_t chat_type, uint32_t count) = 0;
 };

src/tests/network_simulator/README.txt

@@ -37,7 +37,7 @@ Unsolved questions:
 	* should we send ACKs everywhere even upward? No, if we severely limit the depth of random walk.
 	* better distribute routing events, so that the matrix gets filled better?
 	* find a strategy to avoid storing too many items
-	* how to handle cases where a ACK cannot be sent back? The previous peer is going to try indefinitly?
+	* how to handle cases where a ACK cannot be sent back? The previous peer is going to try indefinitely?
 		=> the ACK will be automatically collected by another route!
 	* how to make sure ACKed messages are not stored any longer than necessary?
 	* send signed ACKs, so that the receiver cannot be spoofed.