到目前爲止最簡單的選擇將使用IP/UDP廣播數據包。在計算機上運行的應用程序(運行任何操作系統)都可以在預定義的UDP端口(例如9999)上監聽,而當iOS設備想要'掃描'網絡時,它將發送一個IP/UDP廣播數據包目的地端口爲9999.一旦接收到廣播數據包,計算機上的應用程序就可以響應,因爲它現在知道iOS設備的IP地址,你可以從那裏拿東西。
處理離開網絡的計算機的最簡單方法是在計算機上運行的應用程序將此事實傳達給iOS設備,因爲它已經知道iOS設備的IP地址。但是,如果保持最新的計算機列表至關重要,那麼某種輪詢機制是不可避免的,因爲計算機可能因任何原因崩潰而沒有機會發送再見消息。
可以按如下方式使用多播:計算機爲預定義多播組(例如224.1.1.1)週期性發送IGMP連接,並且iOS設備在想要「掃描」網絡時發送目的地爲224.1.1.1的多播UDP數據包。多播UDP數據包將由計算機接收,因爲它們已經加入了多播組224.1.1.1,然後計算機可以開始與iOS設備進行通信,此時IP地址已知。但是,這似乎過於複雜,並沒有真正提供任何優勢。使用多播的關鍵在於節省帶寬,但節省的帶寬量很小。除非您將大量數據從iOS設備發送到所有計算機,否則沒有理由順其自然。
至於Bonjour,很遺憾我無法發表評論,因爲我沒有經驗,但我仍然會投票支持簡單的廣播以保持平臺獨立......至少在電腦方面。 :)
在試圖實現它之前,想想你如何實現?去掃描你的整個VLAN?發送請求包並等待響應包? – ilansch
好吧,這對我來說也有點模糊。我首先考慮廣播一條消息並等待響應,但是後來我需要知道計算機何時離開網絡,因此我可能需要按一定的時間間隔進行廣播,這可能不適用於iOS,因爲它可能會快速耗盡電池電量。我不確定要走哪條路。 – mrt
這些電腦是否在同一網絡上?他們有靜態IP?這是一種服務器客戶端應用程序嗎?你的控制應用是服務器,其餘的是受控客戶端? – ilansch