MQTT Framework

Share your advanced PureBasic knowledge/code with the community.
User avatar
HeX0R
Addict
Addict
Posts: 1187
Joined: Mon Sep 20, 2004 7:12 am
Location: Hell

Re: MQTT Framework

Post by HeX0R »

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).
User avatar
TheCube
User
User
Posts: 17
Joined: Sat Jul 31, 2021 2:00 pm

Re: MQTT Framework

Post by TheCube »

.... 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.
User avatar
HeX0R
Addict
Addict
Posts: 1187
Joined: Mon Sep 20, 2004 7:12 am
Location: Hell

Re: MQTT Framework

Post by HeX0R »

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

Code: Select all

#USE_BASE64_PAYLOAD = #False
User avatar
TheCube
User
User
Posts: 17
Joined: Sat Jul 31, 2021 2:00 pm

Re: MQTT Framework

Post by TheCube »

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.:

Code: Select all

   Procedure.s BrokerPublish(Topic.s, DatStr.s)     ; Only helper for broker-publishing
     Protected *Payload, L                          ; Call : BrokerPublish("HOME/OUT/cnt", "123")
     
     *Payload = UTF8(DatStr) : L = Len(DatStr)
	   MQTT_BROKER::_PublishViaServer(Topic, *Payload, L, 0, MQTT_Common::#PayloadType_Buffer) 
	   FreeMemory(*Payload)
   EndProcedure
User avatar
HeX0R
Addict
Addict
Posts: 1187
Joined: Mon Sep 20, 2004 7:12 am
Location: Hell

Re: MQTT Framework

Post by HeX0R »

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:

Code: Select all

Procedure.s BrokerPublish(Topic.s, DatStr.s)
     MQTT_BROKER::_PublishViaServer(Topic, @DatStr, Len(DatStr), 0, MQTT_Common::#PayloadType_UnicodeString)
EndProcedure
It will be changed to UTF8 anyway
User avatar
TheCube
User
User
Posts: 17
Joined: Sat Jul 31, 2021 2:00 pm

Re: MQTT Framework

Post by TheCube »

Perfect, everything works fine now. :D
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. 8)
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 :lol:
Post Reply