我想编写一个 iOS 应用程序，它可以通过蜂窝数据网络充当其他 iPhone 的客户端和服务器（即，无需典型的集中式服务器）。目标是通过某种通知方式从 iPhone 服务器向多个 iPhone 客户端共享一系列约 200 条短事件消息，一次一条。 Apple 推送通知服务对于此类通知来说就很好，但没有必要专门使用它。
我认为通过从服务 iPhone 连接到 gateway.push.apple.com 可以将推送通知从一台 iPhone 发送到另一台 iPhone，如 本地和推送通知编程指南，但我找不到其他人讨论这种方法（也许它太明显了？）。
所有这一切的原因是为了避免基础设施的开销。如果这不可行，那么可以采用最小化或避免额外硬件的替代方案。
要求：
- 通信必须[严格]通过蜂窝数据网络进行
- 与 iPhone 服务器单向通信，多播到许多 iPhone 客户端
- 没有越狱
- 理想情况下，服务手机的电池无需充电即可处理此问题
更新 5 /4/11 2:12 AM EST： 需要明确的是，我对使用 APN 没有任何特殊要求；我认为这种设置可能是可行的，但从下面的讨论来看，情况似乎并非如此。但是，我仍然对任何其他可以帮助我通过某种类型的消息传递或类似形式的通信实现相同最终结果的系统感兴趣。
I want to write an iOS app that can act as a client and a server to other iPhones over the cellular data network (i.e., without a typical centralized server). The goal is to share series of about 200 short event messages, one at a time, from the iPhone server to multiple iPhone clients by some means of notification. Apple Push Notification service would be fine for such notifications, but there is no need to use it specifically.
I think sending push notifications from one iPhone to another is possible by connecting to gateway.push.apple.com from the serving iPhone as described in the Local and Push Notification Programming Guide, but I can't find anyone else discussing this approach (maybe it's too obvious?).
The reason for all this is an attempt to avoid the overhead of infrastructure. If this isn't feasible, alternatives which minimize or avoid additional hardware are welcome.
Requirements:
- Communication must be [strictly] over cellular data network
- Wi-Fi isn't available
- Bluetooth doesn't have enough range
- Unidirectional communication with an iPhone server multicasting to many iPhone clients
- No jailbreaking
- Ideally the serving phone's battery will be able to handle this without a recharge
Update 5/4/11 2:12 AM EST: Just to be clear, I don't have any particular requirement to use APNs; I thought it may have been feasible in this setup, but from the discussion below, it sounds like that's not the case. However, I'm still interested in any other system that could help me achieve the same end result with some type of message passing or similar form of communication.
发布评论
评论（1）
理论上，您应该能够编写一个可以连接到 APNS 并向运行您的应用程序的其他设备发送通知的 iOS 应用程序。然而，您的主要问题是实际获取其他设备的“令牌”。当你有一个集中式服务器来完成这项工作时，它总是在线，因此客户端可以通过 http 与它“对话”并自行注册（在此过程中将其令牌提供给服务器）。因此，服务器知道客户端令牌，并且可以使用它们通过 APNS 向客户端发送通知。
但是，在您所讨论的场景中这是不可能的。但这并不是说这是不可能的。也许您可以使用电子邮件帐户 X 来存储所有客户端令牌。每个客户都会向此帐户发送一封电子邮件，其中包含他们的令牌。因此，当另一个“客户端”想要向另一个客户端发送通知时，它可以通过引用电子邮件帐户的收件箱来查找令牌（当然，您可以缓存这些内容并以无数种方式对其进行优化）。
但重点是 24/7 在线的（第三方（例如：电子邮件服务提供商）/您自己的）服务器将如何参与该过程。
让我们知道您在这方面的进展如何。知道这一点会很有趣。
Theoretically you should be able to write a iOS app that can connect to the APNS and send notifications to other devices running your applications. However, your main problem will be to actually acquire the 'tokens' of other devices. When you have a centralized server doing the job, its always online and thus, the clients can 'talk' to it via http and register them self (giving their tokens to the server in the process). Thus the server knows the client token and it can use them to send notifications to the clients via APNS.
However this is not possible in the scenario you are talking about. But this is not to say its impossible. May be you could use an email account X, to store all client tokens. Every client will send a email to this account with their token in it. So when a another 'client' want to send a notification to another client, it can find out the token by reffering to the inbox of the email account (you can cache this stuff and optimize it in a zillion ways of course).
But the point is some how a (third party(ex: email service provider)/your own) server that is online 24/7 will be involved in the process.
Let us know how you progress with this. It would be interesting to know.