Java SMPP 库比较

Java SMPP library comparison

提问by Michael

We're about to begin a project which requires the use of SMPP as the primary integration exchange channel. Now since SMS isn't necessarily core to our business, I'd like to use an SMPP library for Java that will be the least hassle. Aside from riding on the actual protocol, its unlikely we'll need fancier abilities or to ever tweak under the hood.

我们即将开始一个项目，该项目需要使用 SMPP 作为主要的集成交换渠道。现在，由于 SMS 不一定是我们业务的核心，我想使用 Java 的 SMPP 库，这将是最不麻烦的。除了使用实际协议之外，我们不太可能需要更高级的能力或在引擎盖下进行调整。

To that end, I've shortlisted some of the possible options that we have:

为此，我列出了一些我们拥有的可能选项：

• Logica's Open SMPP
• Apache's Camel
• JSMPP
• Twitter's Cloudhopper

• Logica 的开放式 SMPP
• 阿帕奇的骆驼
• JSMPP
• Twitter 的 Cloudhopper

Can someone who's more experienced in their uses throw some of their experiences my way ?

那些在使用方面更有经验的人可以用我的方式抛出一些他们的经验吗？

EDIT: Just to give scope to the use cases, we'll be both sending and receiving SMS'es so the library should hopefully make life easy with both client action and also server listener implementation.

编辑：只是为了给用例提供范围，我们将同时发送和接收 SMS，因此该库应该希望通过客户端操作和服务器侦听器实现让生活变得轻松。

采纳答案by Farhan

I have used both jsmpp& cloudhopper-smppfor separate projects which involved sending and receiving SMS's over smpp in circumstances which involved:

我已经将jsmpp和cloudhopper-smpp用于单独的项目，这些项目涉及在涉及以下情况的情况下通过 smpp 发送和接收 SMS：

• Receiving medium-high number of MOs.
• Sending high number of MTs (upto 70/second).

• 接收中高数量的 MO。
• 发送大量 MT（高达 70/秒）。

Both the libraries fared well, and IMO jsmpp is more user-friendly to jump in and start coding right away. But i had came across a few bugs while using the latest version from github, which still remain unfixed.

这两个库都表现良好，而且 IMO jsmpp 对用户更加友好，可以立即加入并开始编码。但是我在使用 github 的最新版本时遇到了一些错误，这些错误仍未修复。

After having used cloudhopper, i reckon it is well worth the learning curve, which is a wee bit steep compared to jsmpp(subjective).

使用过 cloudhopper 后，我认为学习曲线非常值得，与 jsmpp（主观）相比，这有点陡峭。

回答by Michael

Just an updated to what I finally decided (and how libraries reviewed):

只是对我最终决定的更新（以及图书馆如何）：

1. Logica: Seems promising but I was concerned about the lack of updates/activeness of the community in general. The last meaningful build was yonks ago so not really an investment I wanted to make.

2. Apache Camel: We started off using this but there were some limitations to their library (we needed to insert custom heads to our SMPP packets). To be fair they were fairly prompt in responding to issues on their forums but their build cycles took a little too long for my sprints, so we scratched this.

3. JSMPP: This is the one we ended up using. Was pretty straightforward overall tho it did feel like it expected you to already have a fairly good idea of SMPP in general. Things are in staging so I can't tell you how it performs under production load. Will update when it goes live.

4. Cloudhopper: To be honest this was the one I was keen to use but more because like any geek I wanted to jump on the shiniest newest toy available. I didn't really get adequate responses to any queries we made from the off so was apprehensive to get on board. No reason to adopt a library that will require me to wade thru their codes when other more documented options were available.

1. Logica：看起来很有希望，但我担心社区总体上缺乏更新/活跃度。最后一次有意义的构建是在 yonks 之前，所以并不是我真正想进行的投资。

2. Apache Camel：我们开始使用它，但他们的库有一些限制（我们需要将自定义头插入我们的 SMPP 数据包）。公平地说，他们对论坛上的问题做出了相当迅速的回应，但他们的构建周期对我的 sprint 来说有点太长了，所以我们抓住了这个问题。

3. JSMPP：这是我们最终使用的。总体而言非常简单，但它确实感觉它希望您已经对 SMPP 有一个相当好的了解。事情正在进行中，所以我无法告诉您它在生产负载下的表现。上线后会更新。

4. Cloudhopper：老实说，这是我最喜欢使用的一个，但更多的是因为像任何极客一样，我想跳上最闪亮的最新玩具。对于我们从一开始提出的任何问题，我都没有得到足够的回应，所以我很担心加入。当其他更多文档化选项可用时，没有理由采用一个需要我涉足其代码的库。

回答by Giancarlo Sanchez

I am currently implementing a SMPP solution over Java using Logica's library. It is very easy to use. The following information states the result of the tests:

我目前正在使用 Logica 的库通过 Java 实现 SMPP 解决方案。这是非常容易使用。以下信息说明了测试结果：

Application: Enterprise Java Beans Application deployed in Glassfish 3.1.2.2
Language: Java (using JMS)
Library: Logica SMPP (version 1.3)
Origin (ESME): localhost
Destination (SMSC): Logica SMSC simulator at development server (hosted in Amazon Web Services)
Type: Transciever Asynchronous
Avg sending rate (80%): 246 msg / sec
Low sending rate (15%): 50 msg / sec
High sending rate (5%): 255 msg /sec

应用程序：在 Glassfish 3.1.2.2 中部署的 Enterprise Java Beans 应用程序
语言：Java（使用 JMS）
库：Logica SMPP（版本 1.3）
来源 (ESME)：本地主机
目的地 (SMSC)：开发服务器上的 Logica SMSC 模拟器（托管在 Amazon Web Services 中） )
类型：Transciever Asynchronous
平均发送率 (80%): 246 msg / sec
低发送率 (15%): 50 msg / sec
高发送率 (5%): 255 msg /sec

It is very efficient as long as you stick to the asynchronous mode. If you need to keep a correlation between the message and its response use the "sequence number" that is both in the message and the response.

只要坚持异步模式，它就非常有效。如果您需要保持消息与其响应之间的相关性，请使用消息和响应中的“序列号”。

回答by DenisD

Our SMSC was written on Logica SMPP (v 1.3), it still works really well with enterprise loadings. There has been only a few small issues regarding the library mainly with message_payload, honestly I don't remember other issues. But it's easy to repair because it's an opensource product.

我们的 SMSC 是在 Logica SMPP (v 1.3) 上编写的，它仍然可以很好地处理企业负载。关于库的小问题主要是 message_payload，老实说我不记得其他问题。但它很容易修复，因为它是一个开源产品。

Although I personally trust logica's sources, for small clients I use jsmpp. I agree with @Farhan that it's a bit more user friendly and developing of a simple client takes less time.

虽然我个人相信 logica 的来源，但对于小客户，我使用 jsmpp。我同意@Farhan 的观点，它对用户更加友好，并且开发一个简单的客户端所需的时间更少。

回答by Przemek Pokrywka

I've used both jsmpp and smppapiand found the latter much nicer because jsmpp had only synchronous blocking mode at that time (2010) - not sure if that's still the case.

我同时使用了 jsmpp 和smppapi，发现后者更好，因为当时（2010 年）jsmpp 只有同步阻塞模式 - 不确定是否仍然如此。

The blocking nature of jsmpp become source of big problems when the SMPP server I was connecting to were experiencing some performance problems and responded slower than usual. Suddenly I found all of my threads to be waiting for responses. Migration to smppapi solved the problems obviously.

当我连接的 SMPP 服务器遇到一些性能问题并且响应比平时慢时，jsmpp 的阻塞特性成为大问题的根源。突然间，我发现我所有的帖子都在等待回复。迁移到 smpappi 显然解决了这些问题。

回答by Big Kahuna

I've used Logica SMPP for a production project. It's not actively maintained anymore and there are a few inherent bugs which resulted in having to produce workarounds or actually forking the codebase to fix. Having said that, I've found the API to be very stable and performant (300msg/s).

我已经将 Logica SMPP 用于生产项目。它不再被积极维护，并且有一些固有的错误导致不得不产生变通方法或实际分叉代码库来修复。话虽如此，我发现 API 非常稳定和高性能 (300msg/s)。

I've briefly looked at JSMPP and it has a much nicer API than Logica although there seems to be a large number of defects have not been fixed despite there being on the issue list for a long time.

我简要地查看了 JSMPP，它有一个比 Logica 更好的 API，尽管似乎有大量缺陷尚未修复，尽管在问题列表中存在很长时间。

Just came across Cloudhopper SMPP which seems to be coded in a more up to date style but again it needs more examples. Having to chore through the code base is not attractive. Examples on gituhub are getting better though.

刚刚遇到 Cloudhopper SMPP，它似乎以更新的风格编码，但同样需要更多示例。必须通过代码库做苦差事并不吸引人。不过 github 上的例子越来越好。

回答by huu nhan Tran

Cloudhopper is the best choice, Apache's Camel is also good but it's a very big project that has many interfaces to pdf, salesforce.... that you don't need. Other project is not updated to date. Cloudhopper is maintaining by Telestax and they add some useful features and look like they will give strong support it in future

Cloudhopper 是最好的选择，Apache 的 Camel 也不错，但它是一个非常大的项目，有很多你不需要的 pdf、salesforce 接口。其他项目目前没有更新。Cloudhopper 由 Telestax 维护，他们添加了一些有用的功能，看起来他们将来会提供强有力的支持

Here's stack for easying config Cloudhopper https://github.com/RestComm/smpp-extensionsHere's forked Cloudhopper by telestax (very up to date): https://github.com/RestComm/cloudhopper-smppAlso JainSlee Resource Adapter for whom who's working in telecom field https://github.com/RestComm/jain-slee.smpp

这是用于简化配置 Cloudhopper 的堆栈 https://github.com/RestComm/smpp-extensions这是由 Telestax 分叉的 Cloudhopper（非常最新）：https: //github.com/RestComm/cloudhopper-smpp还有 JainSlee Resource Adapter for who谁在电信领域工作 https://github.com/RestComm/jain-slee.smpp