Ok, trying to write 国家栋樑. Unfortunately I only got the first two characters..国 is Fqge, 家 is ei(, but haven't figured out how to do the last two. Any idea how to get the last two?
Quick suggestion: when shift key is not down, should show lower case letters. When shift key is down, show upper case letters.
I really want to like this. Maybe what the developer can do is to build a simple app that translates a Chinese character into a series of keys. That will ease some of the frustrations on not being able to figure out how to type using this input method. For example, I am trying to type 瓦 but for the life of me I can't figure out how.
edit: removed "shift doesn't work"...does seem to work.
"“Doudou” is a French word that means wubby, the teddy bear or the cloth that children carry everywhere and hug very strongly in their arms before falling asleep. In China the word 豆豆 means the same and is pronounced the same too."
Chinese it's pronounced doughdough (4th tone, if anyone cares) as someone else mentioned below.
When I ran this I gave the server and client 2 cores each. Neither were maxing out the cores.
At about 856K MPS (sent + received) @ 1024 bytes/msg, that's less than 1 GBps. So I can't imagine it being io(net) bound either.
So inconclusive...unfortunately. Need to profile a bit more to know.
Edit: Tho this is TCP based so it's possible that it's netio bound given the protocol overhead. At this message rate, each packet is almost guaranteed to be full size. So we are doing about 600K pps, approximately.
I have not. But I am going to assume you are telling me to learn more about how to calculate my performance numbers. :) Fair point and I will bookmark for future reading.
Author here. A bit of a pleasant surprise to wake up and see this on HN.
Thanks for the detailed response. Here's some answers hopefully can help clarify things a bit.
* Are messages delivered once and only once?
A: MQTT allows QoS 0 (at most once), 1 (at least once), and 2 (exactly once.) The performance numbers in the blog are for QoS 0.
However, SurgeMQ implements all three and there's unit tests for all three. I just haven't done the performance tests for QoS 1 and 2.
* Are messages are messages delivered at least once?
SurgeMQ supports it though the numbers posted are for QoS 0 (at most once)
* Can messages be dropped entirely under pressure? (aka best effort)
No. Currently no messages are dropped.
* If they drop under pressure, how is pressure measured? Is there a back-pressure mechanism?
See above.
* Can consumers and producers look into the queue, or is it totally opaque?
Not sure what this means..sorry..
* Is queueing unordered, FIFO or prioritised?
Ordered, FIFO...MQTT spec requires that messages from publishers to delivered in the same order to the subscribers.
* Is there a broker or no broker?
Brokered
* Does the broker own independent, named queues (topics, routes etc) or do producers and consumers need to coordinate their connections?
Brokers uses topics to route. Publisher publishes to a topic, subscribers subscribe to multiple topics w/ optional wild cards.
* Is queueing durable or ephemeral?
Ephemeral currently. Though MQTT spec requires that any unack'ed QoS 1 and 2 messages be redelivered when the server restarts or client reconnects. So once SurgeMQ meets that spec, it could be considered somewhat durable.
* Is durability achieved by writing every message to disk first, or by replicating messages across servers?
N/A
* Is queueing partially/totally consistent across a group of servers or divided up for maximal throughput?
Currently SurgeMQ is a single server w/ no clustering ability. However, MQTT spec does mention the bridge capability that is a poor man's cluster. Not yet implemented.
* Is message posting transactional?
QoS 1 and 2 starts to be more transactional. QoS 0 is strictly fire and forget.
* Is message receiving transactional?
See above.
* Do consumers block on receive or can they check for new messages?
Block on receive.
* Do producers block on send or can they check for queue fullness?
There's really no comparison tbh. RabbitMQ has been battle tested for years and SurgeMQ is just at its infancy. And RabbitMQ has a lot more enterprise security features that SurgeMQ doesn't have today. So if you are looking for a solution today, go w/ RabbitMQ.
SurgeMQ hopefully will get there someday, but it's not ready today, yet.
Having said that, you can take a look at Tyler Treat's Dissecting Message Queues blog post. He did a fairly detailed performance comparison of the various MQs.
Quick suggestion: when shift key is not down, should show lower case letters. When shift key is down, show upper case letters.