This is pretty cool setup! I am thinking about decisions and will test it on next sailing trip.
Will keep you informed
Hi,
I noticed this thread and wanted to point out that we too are looking for a solution that permits us to send updates from a server to one/many clients. For our MMO (google ironbane) we really need a performant socket solution but I have serious doubts about Meteor Streams which weâre using right now. I havenât tried Streamy yet so we might switch if you guys think that would be a better/more efficient solution.
Having a local collection and subscribing/publishing it does not seem to be an option as Meteor writes to the database on each change which would cause a huge lag in our usecase. We need to do network updates every 0.2 seconds, like any realtime multiplayer game but so far Iâm not sure which path we should proceed with.
If Iâm not mistaken Streamy is built on top of meteor streams, but should look at the source to confirm. Either way Meteor Streams will probably be more performant as it has less overhead calculations. In other words with Meteor streams youâll have to write all the code yourself but itâll be adjusted to your exact needs, so youâll be able to optimize.
Also if you need very fast database performance you should look into redis as a database.
If these solutions donât fit your needs youâll probably have to write your own solution, which wouldnât be a surprise if youâre building a realtime mmo.
Hi @nlammertyn, @nikke
First of Streamy and MeteorStreams are independently solutions with different architectures.
We are working very successful with local meteor collection and own publisher methods. For our solutions it is also absolutely nice feature, that we have access to previous documents on local collection as well.
@nikke what you are looking for should be realizable by observe methods as well. Have a look at this timer demo which will update every 0.1 second.
Maybe you get a hint out of that.
Cheers,
Tom
Meteor Streams works fine for now, itâs just an outdated and dead project. Itâs bound to cause problems later on as Meteor improves over time. We actually did build our own solution before Meteor came out using socket.io, but now weâd like to stick with Meteor as thatâs a managed solution and has caused us far less headaches than in the days of node.js, grunt, etc. Integrating a solution like socket.io that runs simultaneously with Meteor is not an option as a socket.io server would require an extra port, breaking SSL. Also having two websocket servers is just absurd I guess.
Thanks for the example. I was not aware that one could publish on the server like that. Is the server still creating a mongodb collection behind the scenes? E.g. is the Ticker counter being persisted somewhere? I guess it doesnât matter as long as it doesnât impact performance, but Iâm still curious to know.
The main problem weâre facing is that we mostly need to send single events to users. Consider a player that has attacked a monster. Weâd need to send an attack event using the monster ID and the weapon ID theyâre carrying.
player.stream.emit('combat:attackEntity', {
victimEntityUuid: victimEntity.uuid,
itemUuid: item.uuid
});
Note that we donât care about saving this event, or having access to previous documents. Itâs just fire and forget. Using a local collection for this becomes hard unless we use an âeventsâ collection and publish it to each user, that acts as a message bus. I believe this is exactly what Meteor Streams is doing, except that it is outdated so we might take a closer look at your example. Thanks again!
@nikke - I am pretty sure you easily can switch to local collections because MeteorStreams is exactly that. See: https://github.com/arunoda/meteor-streams/blob/master/lib/server.js#L38-L69 and https://github.com/arunoda/meteor-streams/blob/master/lib/server.js#L38-L69 as relevant source parts. So timing isnât different from that.
Also there is no mongo Collection created at database level, only the mini-mongo on client side has its data driven collection. On server side it is just through flown value.
I will create an example for your usecase later on tonight.
Cheers
Tom
Hi Tom,
Do you have any more information/a repository for your meteor/arduino/mqtt/streaming configuration? We are just beginning our application requirements in an effort to create a âsmart townâ and open-source the app to âengage it.â
We would like to tie in a LoRa gateway JSON data and map publications and lat/lng in âreal-timeâ.
Any help will be much appreciated. Iâd welcome a brief consultation too!
Thanks, much.
Patrick
Hi @artsandideas - I may not yet use information about our projects in public but if you write me a PM with your needs, I can give some advises from our experiences.
Cheers
Tom
How would you use that:
var Ticker = 0;
Meteor.publish('streaming', function(){
// safe reference to this session
var self = this;
// insert a record for the first time
self.added("streamer", "timer", { ticker: Ticker });
// from now only update that record continously every second
var handleInterval = Meteor.setInterval(function() {
self.changed("streamer", "timer", { ticker: ++Ticker });
}, 1000);
self.ready();
self.onStop(function(){
handleInterval && Meteor.clearInterval(handleInterval);
});
});
to broadcast a certain message to all connected clients? Iâd like to call a function from the client on a certain event to publish on all subscribers.
Iâm currently having trouble to change the Ticker
var from the client.
Any hints are greatly appreciated.
Hi @atez
You do not need to do that in a timed publishing method. You may send out to all / filtered subscribers on that method
Got luck
Tom
See also my question and first / alternate approach on StackOveflow:
and my answer later here in thread with a functional MeteorPad example
Hi @atez
I checked my own written down infos and got some erratas. Here you find a functional meteorpad where you may connect with a number of browser windows and push messages to all subscribed.
When starting a new window / subscription every one gets a warm welcome message. After that you may press the button and see how the buddy sends messages to others. You always see the last 5 messages.
Hope that makes it clear for anbody.
MeteorPad Example for Publish and Subscribe and Broadcast messages
Cheers
Tom
Very simply, I think this is a genuinely sesmic event.
There are a variety of very cheap linux boards planned, but the Pi Foundation has
trounced everyone. Iâve been touting the Raspberry Pi as the ideal platform for IoT local hubs for a while, but with the advent of the Pi Zero, full linux machines as IoT edge devices are not only possible, but very likely to be the default platform. The exceptions are for very low power, battery powered applications, or those with extreme real-time requirements.
I think this was a red letter day.
I tried all of the Meteor packages for IoT related data transfer protocols and gave up on all of them. In the end I used the node package net and it worked well. My guess is I had to write more lines of code than if I used a Meteor package but it really wasnât that bad. Details on the net package are here: https://nodejs.org/api/net.html
In terms of IoT hardware, I agree with @mkarliner. I am working on an IoT project for plant floor data collection and we are very interested in Pi Zero and C.H.I.P. I think Pi Zero with networking adapter comes to $11 plus setup time where C.H.I.P. comes with networking libraries and hardware built in for $9. Pi has better ecosystem obviously. I would post the publications,etc. but the IP is owned privately so here is the pseudo-code similar to what @tomfreudenberg was discussing, with some additions.
- Client logs in and adds device using device master including information on host and port
- Client selects which device to connect to; app saves the host and port in Session variables.
- A Meteor.publish function exists on the server which basically runs a Meteor.setInterval every 500ms to see if the host and port information are valid before opening a socket, reading the output, and closing the socket using net.
- A client collection is created to save the output in and an observe function waits for changes and then updates the local collection and saves the new value to another Session variable that can be used in template helpers
@atez if you create a field somewhere to change the ticker manually, have your client code save that value in a Session variable. Meteor subscribe can pass variables to Meteor publish, so inside your this.autorun on the client you should save the Session variable as a local variable and then pass it to the subscribe function. Then use it.
I have a feeling that the Pi Zero will lead to boosted sales of the model B and B2, as people do the same calculation as you and opt for the âlarge friesâ version. OTOH, Iâm interested in Pi Zero and LoRa, so Iâm not automatically putting a wifi dongle on.
Off topic, but you might want to look at our platform ThingStudio, http://www.thingstud.io which is a meteor based IDE for making IoT user interfaces. I realise that its not quite what weâre discussing here, but just sayingâŚ
Hi Roger, how do you handle security and authorization when using the net package? Do you have established some kind of key-exchange or something else?
The system runs on private networks so the firewall is the first layer. And then the connection times out if you poll too slowly or quickly so you have to know how fast to open and close connections. And finally you have to send the device a certain letter before it will tell you what the read-out is and you canât read more than once in a connection. The device I am connecting to doesnât support authentication so this is what we worked out. In general I assume I will need to develop some kind of character exchange for other similar devices or where we build the one we are thinking of building.
@mkarliner (or anyone), hi I watched your DevShop talk in London (that was you right?) on using Meteor for IoT. One of the things I have been investigating is whether it is worth it in the long run to use MQTT to communicate with IoT devices instead of DDP, given the uncertainty of the future of DDP with the coming of Apollo, which has yet to be discussed in the Transmission podcast.
That said, are there any significant advantages of using MQTT than DDP for IoT communication?
Hi Richard ( @lai )
Not sure what is the important reason for Mike ( @mkarliner ) but for us it was a decision on infrastructure. In case that we had really good experiences with rabbitMQ servers, we choosed MQTT as transport service for the IoT devices. That allows us to write down very easy IoT clients (just pushing there messages via MQTT) and could believe in delivering and monitoring the infrastructure without the need to invest into development there. So we just take out the IoT messages on our server side and put them into the main meteor app.
For senders like camera, gps, temperature, barometer ⌠it really works fine. Also you we found MQTT libs for a number of devices we tried out (Raspi Zero, Onion, etc.)
Have a nice weekend
Tom