我正在構建一個既有服務器又有客戶端的Objective-C應用程序。客戶端可以將更新發送到服務器，並且服務器需要能夠向每個連接的客戶端發送更新。我一直在想如何最好地實施這個系統，但是我正在尋求你的建議。Objective-C網絡 - 最佳實踐？
目前，我在想，當新的更新可用時，服務器將使用線程將更新發送到每個客戶端。如果客戶端超時，它們將斷開連接。 我有很少的網絡經驗，所以我問你的見解。
你認爲這個系統可以正常工作嗎？ 如果是這樣，你有關於如何執行線程的任何建議？你可以指點我的任何NS課程？我想我應該可以使用某種隊列。
還有其他想法嗎？
編輯：我不希望客戶端數量大大超過50左右，在最大。
只要客戶端和服務器的OS X應用程序和既可以在Objective-C使用Cocoa框架寫的，我會強烈建議你看一看在Distributed Objects（DO）技術在可可。我不會嘗試在這裏給出分佈式對象的教程，只是解釋它爲什麼可能有用...
DO爲您處理異步網絡細節（您的所有客戶端更新可能發生在單個線程上）。另外，與遠程對象進行通信的語義（客戶端到服務器或反之亦然;一旦連接建立，DO就是雙向的）與進程內通信非常相似。換句話說，一旦你有一個對遠程對象的引用（真正的NSDistantObject作爲連接另一端的對象的代理），你的客戶端代碼可以發送消息到遠程對象，就好像它是本地的：
[remoteServer update:client];
或
[[remoteClientList objectAtIndex:i] update:server];
從服務器。在閱讀Distributed Objects programming guide後，我將留下設置連接的細節，以及獲取remoteServer或remoteClient的參考信息。
使用DO的缺點是你被綁在可可上;這將是非常難難以編寫非可可客戶端或使用Distirbuted對象進行通信的服務器。如果有機會你可能想要使用非Cocoa客戶端或服務器實現，則不應該使用DO。在這種情況下，我會推薦一些簡單的東西，並提供大量的跨平臺和語言支持。基於HTTP的REST風格的API是一個不錯的選擇。查看Cocoa URL Loading System文檔以獲取有關如何實現HTTP請求和響應的信息。查看Apple的CocoaHTTPServer示例代碼或same name的code.google.com項目，獲取有關在您的Cocoa代碼中實現HTTP服務器的信息。
作爲最後一個選項，如果你想實現你自己的網絡協議，你可以看看Cocoa Stream Programming Guide。 NSStream的子類將允許您在網絡套接字上偵聽並處理來自該套接字的異步讀/寫操作。很多人爲此使用AsyncSocket。它包裝（較低級別的）CFStream和CFSocket，並使編寫網絡代碼更容易一些。
如果您想在跨平臺應用程序中使用DO，GNUStep可以提供很多幫助，儘管此時您可能不想爲GUI使用GNUStep。 – user57368 2009-02-19 21:49:43
當服務器向客戶端發送更新時，只需要一個線程處理它們，並且只使用異步套接字就可能更容易。當然，這取決於您需要處理的客戶數量。
我不知道你打算如何設計你的系統，但通常服務器無法連接到客戶端;客戶必須發起溝通。對於50個客戶端的下限，您可能不會看到類似於網絡服務器/客戶端的實現......
也就是說，基本上有兩種方式來處理客戶端服務器通信： 1.客戶端調查服務器定期獲取更新 2.客戶端保持連接對服務器開放，並且服務器以衆所周知的方式響應（如雙方都理解的那樣）協議。
在蘋果開發者方面有幾個網絡示例。 我會建議你檢查一下是URLCache，它可以下載。 從Apple的文檔引用這個例子：
Urlcache文件是一個示例iPhone應用程序，演示如何下載資源從網上，它存儲在應用程序的數據目錄，並使用資源的本地副本。 Urlcache文件還演示如何實現一對夫婦緩存策略：
一個有趣的選擇是從Jens Alfke的BLIP協議。這就像是一個簡化的版本BEEP：面向消息的網絡系統。它基本上爲雙向消息管道提供了低級抽象，因此您可以專注於將通信協議層疊到頂層。
它有一些值得追隨的人，比如Marcus Zarra（CoreData聖經的作者）和Flying Meat軟件的Gus Mueller。
如果我要再次這樣做，我會考慮使用AMQP或類似的消息傳遞協議，以便更新可以按推。只是思考的食物。 – Allyn 2010-11-01 16:02:00