Window Size parameter

[tahseenjamal]

I cannot find window size parameter, can someone help if there is such a parameter or not

[eigenein]

Hi @tahseenjamal,

I assume you're referring to the asynchronous mode? This is up to the user code as smpplib does not have any internal queue for outgoing PDUs, all the commands are sent immediately, and you are free to read responses asynchronously

Your messaging gateway may have the window size parameter, but it is not up to the client to change it

[tahseenjamal]

Hi @eigenein thanks for quick response. What am aware of is that window parameter is passed at the time of connection creation. Basis that SMPP allows multiple submissions before it could response. Else by default it accepts one request, then responds to that then accepts another one.

So even if I try thread using single connection, it won't work

[eigenein]

What am aware of is that window parameter is passed at the time of connection creation

I don't believe so, but I might be missing something, of course. Neither of bind_transmitter, bind_receiver, or bind_transceiver defines a window size parameter in the specs. Anything that I could find on Google was related to the server-side settings

Could you point me to any specs that say it's a connection time thing?

[tahseenjamal]

@eigenein check this link

https://nordicmessaging.se/tech-notes/window-size-explained/

[eigenein]

It shows an example of the WINDOWSIZE option of the CONNECTOR setting in the EMG configuration. That's a server-side option, not a part of SMPP connection negotiation

[tahseenjamal]

In Golang SMPP https://github.com/fiorix/go-smpp/blob/a82a321cf1d80532c7cffeb2ba8cd607da46513e/smpp/transceiver.go#L32

it is passed in the binding and in production I have seen it increases the performance of submission

What would be equivalent of this in python smpp ? using threads for same connection ?

[eigenein]

In go-smpp it appears to be handled by the library code, just as I would expect, it isn't passed into the binding PDU

In python-smpplib there is no such functionality. However, you do not have to wait for a response to come in order to send another request. Functions like send_message() only send the request, they do not wait for a response. If you called client.listen() in a separate thread, you would not be blocked from sending a many requests as you would like

[code-of-kpp]

Yes, in this sense we are way more low-level I guess. The library just manages the packages. You can introduce custom logic to the client refusing to send a message after WINDOW of them were already sent, but haven't received corresponding ack messages yet. Depending on how exactly you define it, you can think about our client implementation as having either 1 or infinite window size.

…

-- -- Best Regards