這是不好的編程？

-1

DateTime dtExpire = DateTime.Now.AddSeconds(90); 
while (client.Connected && DateTime.Now < dtExpire) 
{ 
    if (client.Available == 0) continue; 
    //or can also use: if (!networkStream.DataAvailable) continue; 

    dtExpire = DateTime.Now.AddSeconds(30); 

    //now do stuff with client via stream 
}

確保客戶端不會比服務器花費更多時間的目標是願意等待傳入消息。當然，這段代碼位於Try/Catch塊以及Using Stream塊中，因此服務器將正常處理丟棄的連接或任何其他套接字異常。

基本上，我只是想知道是否有更好的方法來處理這個問題。謝謝。

來源

2011-10-15 Paul Rivera

這與TCP無關，除了一些與實際問題無關的模糊網絡操作。請從您在此處使用的語言開始重新編號（c＃？） –

您想要做什麼？ – Ekk

這可能會更好的代碼審查 – TMB

使用ReceiveTimeout屬性可以指定等待傳入消息的時間。當您使用Receive方法（或其方法族）並且發生超時時，將拋出SocketException。

client.ReceiveTimeout = 90;

如果您必須異步完成此操作，那麼您的代碼將會更加複雜，但看起來並不像您那樣。 Receive本身應該做的工作，因爲它會阻止當前線程。

來源

2011-10-15 04:03:15 Marlon

謝謝，那就是我一直在尋找的;我已經添加了ReceiveTimeout。 –

這叫做busy waiting。

即使沒有「真正」的工作要做（即當你正在等待client.Available變得與0不同時），你基本上會堵塞CPU。幸運的是，你的忙碌等待有一個超時，所以至少它不會永遠堵塞CPU。

是否可以更有效地做到這一點只取決於client是什麼以及是否實施更有效的等待策略。

如果沒有，那麼你就可以用某種形式的忙等待卡住了，但不是全部丟失 - 如果你能在檢測client.Available的變化，然後做容忍輕微的延遲......

if (client.Available == 0) { 
    Thread.Sleep(max_delay_you_can_tolerate); 
    continue; 
}

...會對CPU帶來壓力。

---編輯---

如果client事實上是一個Socket，看看Blocking和ReceiveTimeout性能。

來源

2011-10-15 04:06:52

這是不好的編程？

回答

相關問題