https://github.com/ayrapetovai/vertx-smpp

SMPP client and server for Vert.x
https://github.com/ayrapetovai/vertx-smpp

java smpp vertx

Last synced: 3 months ago
JSON representation

SMPP client and server for Vert.x

• Host: GitHub
• URL: https://github.com/ayrapetovai/vertx-smpp
• Owner: ayrapetovai
• License: apache-2.0
• Created: 2022-03-20T15:41:29.000Z (about 3 years ago)
• Default Branch: main
• Last Pushed: 2022-11-23T21:36:53.000Z (over 2 years ago)
• Last Synced: 2025-01-31T23:03:12.939Z (3 months ago)
• Topics: java, smpp, vertx
• Language: Java
• Homepage:
• Size: 423 KB
• Stars: 3
• Watchers: 2
• Forks: 4
• Open Issues: 6
• Metadata Files:
  • Readme: README.adoc
  • License: LICENSE

Awesome Lists containing this project

README

        
= vertx-smpp

image:https://img.shields.io/badge/smpp-3.4-blue[]

image:https://img.shields.io/badge/vert.x-4.2.5-purple.svg[link="https://vertx.io"]

image:https://img.shields.io/badge/java-11-purple[]

image:https://img.shields.io/badge/production-not%20ready-red[]

SMPP client and server based on 'Cloudhooper by Twitter' https://github.com/fizzed/cloudhopper-smpp/tree/netty4[source code] ported to netty4 by *fizzed*. This version is adapted to Vert.x, it is not production ready yet.

Server https://github.com/ayrapetovai/vertx-smpp/blob/main/src/test/java/io/vertx/smpp/demo/EchoServerMain.java[example].

Client https://github.com/ayrapetovai/vertx-smpp/blob/main/src/test/java/io/vertx/smpp/demo/PerfClientMain.java[example].

This project needs help and wants to be a part of Vert.x.

== Performance

Hardware: Intel Core i7 2.6 GHz, 6 cores, L2 256 Kb, L3 9 Mb, 2x8 Gb RAM 2.4 GHz.

Client: 1 thread, 1 session, window size 600 (mean 38, max 365), with text (GSM8 encoded) of 160 chars in each submit_sm request, SSL is off; bind TRANCEIVER, sends submit_sm, deliver_sm_resp.

Server: 1 thread, 1 session, window size 600, SSL is off; sends submit_sm_resp, deliver_sm.

        | requests | responses | throughput | latency,ms | time,ms

 submit |  5000000 |   5000000 |     132597 |      0.271 |   37708

deliver |  5000000 |   5000000 |     132597 |      0.067 |   37708

== Client Features

Legend: [v] done, [0] partially done, [-] not done.

. [v] Supports SSL, but does not support Server Name Indication (using several ssl-certificates on the same host).

. [v] Bind to MC as `Transmitter`, `Receiver`, `Tranceiver` by calling bind method and pass host and port to it.

    .. [v] User can send `SystemId`, `Password`, `SystemType`, `Address` in bind_request.

    .. [v] User can specify ClientSessionConfigurator *onCreated* callback to be notified when connection is established and session is created and ready for use, it fires before BindFuture *onSuccess* but provides the same session instance.

    .. [v] User can specify ClientSessionConfigurator *onOverflowed* and *onDrained* callbacks. The *onOverflowed* is called when write buffer of the socket is full and no more requests can be send, user is supposed to do pause on sending. The *onDrained* is called when write buffer on the socket is lowered under the low watermark, and there is some space in write buffer to write requests, user supposed to resume sending.

    .. [v] Also, library sends interface version in bind_request.

. [0] User can set timeouts for operations *bind(...)*, *send(...)*, *close(...)*:

    .. [0] User can specify bind timeout in *bind(...) method call or by setting option 'requestExpiryTimeout', bind request in this case.

    .. [-] User can specify timeout for *close(...)* operation on client. Which handicapped time for client to close all sessions.

    .. [-] User can specify timeout for *close(...)* operation on session. Which handicapped time for session to wait for window to be drained, for `unbind` to send and for `unbid_resp` to be received all together.

    .. [v] User can specify 'offerTimeout' for *send(...)* operation, which is desired duration of waiting on window to abele to take the request. If widow continues to be full during all the waiting time, the send future will be failed with *onWindowTimeout* callback call.

. [v] User can send requests `submit_sm`, `deliver_sm`, `query_sm`, `data_sm`, `enquire_link` and [-] `generic_nack` as response. But user cannot send, `bind_receiver`, `bind_trancriver`, `bind_transmitter`, `unbind` and corresponding responses.

    .. [v] For send future user can assign a callback *onSuccess*, that will be called when request will be answered with corresponding response or `generic_nack`.

    .. [v] For send future user can assign a callback *onFailure*, that is called if any of send error event happened.

    .. [v] For send future user can assign a callback *onDiscard*, that is called on session close, if option 'discardAllOnUnbind' is set to *true*. There is no guarantees that request was not sent on network connection, nor response was not arrived at network connection.

    .. [v] For send future user can assign a callback *onWriteFailed*, that is called if netty cannot write request to a session channel.

    .. [v] For send future user can assign a callback *onTimeout*, that is called if request was successfully offered to the session window and sent over the network connection, but response was not received in desired time duration set in option 'requestExpiryTimeout'.

    .. [v] For send future user can assign a callback *onChannelClosed*, that is called when connection is reset or if it was reset on the moment user code did a *send(...)* operation.

    .. [v] For send future user can assign a callback *onWindowTimeout*, that is called when request is expired in window, that means that request was sent over the network connection but ro response was received until the duration ends, that was set in option 'requestExpiryTimeout'.

    .. [v] For send future user can assign a callback *onWrongOperation*, that is called if session state is not suitable for request type.

    .. [v] For send future user can assign a callback *onNackked*, that is called if the `generic_nack` pdu was received as a response, and it's sequence number corresponds to the sequence number of the request.

    .. [v] For send future user can assign a callback *onWriteOverflowed*, that is called when write buffer of the channel becomes full. This means that the receiver of requests (server) cannot take that many requests, and client have to slow down sending.

    User is supposed to do *pause* on the source of requests in case of being notified with *onWriteOverflow*. The session *onOverflowed* callback has check interval no less than 1ms, whereas the send future *onWriteOverflowed* is called as often as send attempts are made.

    .. [-] User can use all vertx native API of 'send future', as that *compose(...)* and so on.

    .. [v] User can react on `generic_nack` with no sequence number by passing callback to *configuratior.onUnexpectedResponse(...)*.

. [-] Client keeps track of metrics for all sessions, which are available to user.

. [v] User can *doPause()* receiving of PDUs, can *doResume()* receiving, and check is session is paused by *isPaused()*.

. [v] User can obtain a size of a session window with *getWindowSize()* operation on session.

. [v] If network connection gets reset or user decides to close connections by *session.close(...)*, the callback session *onClosed* is called. Also, all send futures get *onChannelClosed* called. The session *onClosed* callback purpose is to make user to be able to react on session close event when it was not initiated by them.

. [0] User can unbind session by calling *close(...)* method.

    .. [v] Close operation is idempotent.

    .. [-] User can specify timeout for session to close.

    .. [v] User can specify whether they want closing routing to await for window to be drained and send or they want window to be discarded on session close.

. [-] Client can automatically do backpressure if channel's read queue or write queue are overflowed. User can specify lower and higher watermarks.

. [-] User can update session options (timeouts, windows size, callbacks) while session is open or bound.

== Server Features

. [-] Each session keeps track of metrics, available to user.

== Usage

User code manages client/server session objects by itself.

== Building

To package library:

[source,bash]

----

gradle clean assemble

----

== Load Testing

To load SmppGateway, run EchoServerMain, SmppGatewayMain and run jmeter:

[source,bash]

----

jmeter -n -t {$PROJECT_DIR}/src/test/resources/JmeterSmppGateway.jmx

----

== Contribution

* Need help implementing metrics. Even just advice of how to do it the Vert.x way.

* API criticism and suggestions are welcome.

== Help

* https://smpp.org[SMPP Specification]

* https://vertx.io/docs/[Vert.x Documentation]

* https://groups.google.com/forum/?fromgroups#!forum/vertx[Vert.x User Group]

* https://gitter.im/eclipse-vertx/vertx-users[Vert.x Gitter]

'''

Consider link:TODO.adoc[todo]