PureBasic Forums - English

I think you probably should switch to a different protocol, your tests are not really what I'd consider a typical use case for MQTT.
Anyway, I've added a more dynamic delay, not sure about useful settings, maybe you can set it to your needs (_ServerThread(), #PB_NetworkEvent_None handling).

.... tests are not really what I'd consider a typical use case for MQTT

You are right. But like I said, I just want to explore the limits. Later, publishes are only every 200-500ms over a real network (with pingtimes 2-20ms), but then I know that it will still work even if the host is briefly 90% full for a short time.

Nice idea, your added a more dynamic delay, thank you.
But unfortunately always the highest delay level is executed because always Packets=0. (Placed Debug's in the Case #PB_NetworkEvent_None)
I don't know in which scenario there will be appear more packets .

The thought occurs to me that it's not about the broker-buffers or -lists (which are handled fast and ready), but simply the network buffer is filling up.
So, the publishing for "maybe minutes" after stopping _PublishViaServer() is maybe just fed from the (64K ?) network buffer.
Unfortunately you can't read the network buffer fill level, unless it's empty, of course.

Thanks overall, it's not a priority, I'm already very satisfied.

You might win also some performance, when you disable the base64 encoding.
In MQTT_Common.pbi:

Hi,
I was "out of order" for a few days, but now I tried a comparison regarding your suggestion.
I think I noticed about 20% better throughput if I complie the MQTT_Broker with #USE_BASE64_PAYLOAD = #False.
I cannot fully test it, because a problem occured:
Publishes from broker to clien appear to have the wrong encoding, looks a bit like the ASCII unicode problem from the old days.

Logwindow Broker publish: #USE_BASE64_PAYLOAD = #False
Manual testdata published > HOME/OUT/cnt=4
Manual testdata published > HOME/OUT/data={"CNT":4,"EPOCH":1716135317,"%1":"#R318D04610"}

Logwindow Client (doesn't matter #USE_BASE64_PAYLOAD = #True or #False)
Rcvd published Topic: 'HOME/OUT/cnt'->p (Q=0, D=0, R=0, M=0)
Rcvd published Topic: 'HOME/OUT/data'->P (Q=0, D=0, R=0 M=0)

Nearly the same applies when using MQTT-Explorer-0.4.0-beta1.exe
cnt = �
data = P����p'P�

But publishes from client to broker seem to be understood correctly, Logwindow Broker shows readable text.

This is my "helper" for manual broker-publishes, if important.:

I think, there was a @ too much in the broker.pbi, could you please try the latest version?

btw.:
Your helper procedure is not neccessary, just use: It will be changed to UTF8 anyway

Perfect, everything works fine now.
Then, I make my not so realistic MQTT speed tests, to scratch the limitations.

Setups:
- 4 Clients compiled .exe running (Two Tests with #USE_BASE64_PAYLOAD = #True or #False)
Logwinodw limited to 300 Lines to avoid speed loss with e.g. >1000 Lines
- 1 Broker running from PB6.04 (C-Compiler) (Two Tests with #USE_BASE64_PAYLOAD = #True or #False)
Has no logging-output during Test (publish all 7-10ms something short)
- Connected via localhost executed on one pc

Result: For me there is no more measurable difference in terms of BASE64_PAYLOAD true or false,
But that doesn't matter because it's twice as fast compared to Broker.pbi V1.13 in all variations of setups above.
In real that means:
After stopping the (far too many) broker publishes after a certain time, the clients continued receiving, for example 20 seconds,
now with V1.14 just only 10 seconds.

btw.:
My old BrokerPublish()-Procedure is inspired by your example_OnEvent_Button().
The new version is nicer and smaller (thanx), but without further speed improvement.

I'm glad that my annoyance at least uncovers small bugs