短信应答延迟的概率分布
我正在编写一个使用短信作为通信的应用程序。 我选择订阅短信网关，它为我提供了执行此操作的 API。
该 API 具有发送和拉取新消息的功能。然而，它没有任何类型的推送功能。
为了最有效地进行查询，我正在寻找有关人们在回复短信之前等待多长时间的数据 - 作为概率函数。
额外信息：
- 该应用程序是交互式的（尽可能），所以我认为时间将与现实生活中的人与人之间的交流非常相似。
- 我不认为个人风格的差异会对正确的查询时间和频率产生很大的影响，所以平均数据应该没问题。
更新
我对收到的许多精彩答案印象深刻并感到荣幸。我得出的结论是，我最好的方法是一些适应性强的启发式方法，包括指数（或多项式）退避。
一直以来我都会收集统计数据以供以后分析。也许有些东西会出现。我想我会欺骗从概率分布生成轮询频率的算法。那会很有趣。
再次感谢多次。
I'm writing an app using sms as communication.
I have chosen to subscribe to an sms-gateway, which provides me with an API for doing so.
The API has functions for sending as well as pulling new messages. It does however not have any kind of push functionality.
In order to do my queries most efficient, I'm seeking data on how long time people wait before they answer a text message - as a probability function.
Extra info:
- The application is interactive (as can be), so I suppose the times will be pretty similar to real life human-human communication.
- I don't believe differences in personal style will play a big impact on the right times and frequencies to query, so average data should be fine.
Update
I'm impressed and honered by the many great answers recieved. I have concluded that my best shot will be a few adaptable heuristics, including exponential (or maybe polynomial) backoff.
All along I will be gathering statistics for later analysis. Maybe something will show up. I think I will cheat start on the algorithm for generating poll-frquenzies from a probability distribution. That'll be fun.
Thanks again many times.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
在没有任何实际数据的情况下，最好的解决方案可能是编写代码，以便应用程序根据当前的响应时间历史记录调整等待时间。
基本思路如下：
第一步：设置初始拉动频率为每x秒一次。
步骤2：在y时间内以上述频率拉取消息。
步骤3：如果你发现消息总是在等你拉，减少x，否则增加x。
几个设计考虑因素：
永远调整或一段时间后停止
您可以永远重复步骤 2 和 3，在这种情况下，应用程序会根据短信模式动态调整自身。或者，您可以在一段时间后停止以减少应用程序开销。
调整标准：每个客户或所有客户
您可以选择在步骤 3 中针对每个客户或针对所有客户进行调整。
我相信 GMAIL 的 smtp 服务也遵循同样的原理。
In the absence of any real data, the best solution may be to write the code so that the application adjusts the wait time based on current history of response times.
Basic Idea as follows:
Step 1: Set initial frequency of pulling once every x seconds.
Step 2: Pull messages at the above frequency for y duration.
Step 3: If you discover that messages are always waiting for you to pull decrease x otherwise increase x.
Several design considerations:
Adjust forever or stop after sometime
You can repeat steps 2 and 3 forever in which case the application dynamically adjusts itself according to sms patterns. Alternatively, you can stop after some time to reduce application overhead.
Adjustment criteria: Per customer or across all customers
You can chose to do the adjustment in step 3 on a per customer basis or across all customers.
I believe GMAIL's smtp service works along the same lines.
好吧，我建议找到一些按地理位置和年龄组划分的每日短信/短信使用情况的统计数据，并得出每日平均值，但这并不是对所有人的精确测量。
well I would suggest finding some statistics on daily SMS/Text Messaging usage by geographical location and age groups and come up with an daily average, it wont be an exact measurement for all though.
好问题。
考虑到人们可能有多项任务，而回复短信可能是其中一项任务。如果每个任务花费的时间呈指数分布，则回复短信的时间就是这些任务完成时间的总和。 n 个独立同分布随机变量之和服从伽玛分布。
文本返回之前的任务数量也具有离散分布 - 假设它是泊松分布。我没有时间推导出结果分布，但使用 @Risk 对其进行模拟，我得到了威布尔分布或伽玛分布。
Good question.
Consider that people might have multiple tasks and that answering a text message might be one of those tasks. If each of those tasks takes an amount of time that is exponentially distributed, the time to get around to answering the text message is the sum of those task completion times. The sum of n iid random variables has a Gamma distribution.
The number of tasks ahead of the text return also has a dicrete distribution - let's say it's Poisson. I don't have the time to derive the resulting distribution, but simulating it using @Risk, I get either a Weibull or Gamma distribution.
SMS 是一种存储转发消息服务，因此您必须添加各个 SMSC（短信服务中心）可能添加的延迟。如果您要连接到大型聚合公司（Sybase、TNS、mBlox 等）商业批量 SMS 提供商（Clickatel 等）之一，那么您需要允许消息穿越其网络以及运营商网络。 您使用的是较小的商店，那么他们很可能使用的是 GSM 调制解调器（或多个调制解调器），并且可以接收和处理（以及推送）的消息有吞吐量限制。
如果 直接连接或作为 CP（内容提供商）向您发送的大佬 MO（移动发起）消息之一应该需要不到 5 秒的时间。再加上移动订户回复所需的时间。
我想说的是，我以前从事过的服务中的轶事证据表明，移动订户需要提供简单的答复，通常在 10 秒内或者根本不需要。
如果您要轮询特定回复，我会在 5 秒和 10 秒时轮询，然后应用指数回退。
所有这些都是从北美的角度来看的。欧洲将相当接近，但像非洲、亚洲这样的地方会慢一些，因为网络速度慢一些。 （除非您直接连接到运营商，即使这样，其中一些还是很慢）。
SMS is a store-and-forward messaging service, so you have to add in the delay that can be added by the various SMSCs (Short Message Service Centers) along the way. If you are connecting to one of the big aggregation houses (Sybase, TNS, mBlox etc) commercial bulk SMS providers (Clickatel, etc) then you need to allow for the message to transverse their network as well as the carriers network. If you are using a smaller shop then most likely they are using a GSM Modem (or modems) and there is a throughput limit on the message the can receive and process (as well as push out)
All that said, if you are using a direct connection or one of the big guys MO (mobile originated) messages coming to you as a CP (content provider) should take less than 5 seconds. Add to that the time it takes the Mobile Subscribers to reply.
I would say that anecdotal evidence form services I've worked on before, where the Mobile Subscriber needs to provide a simple reply it's usually within 10 seconds or not at all.
If you are polling for specific replies I would poll at 5 and 10 seconds then apply an exponential back off.
All of this is from a North American point-of-view. Europe will be fairly close, but places like Africa, Asia will be a bit slower as the networks are a bit slower. (unless you are connected directly to the operator and even then some of them are slow).