Keeping the noise down

 These little ESP8266 NodeMCU modules are great little things.

You can get them to boot up, connect to a router and then immediately start broadcasting their presence over UDP. What's the point in that?

Well, the idea is that we would have our app listening on a UDP port, and when an incoming message is received from a new device just booting up, the server could "shout back" at it.

When the NodeMCU client hears the server shouting back at it, the client will have the server's IP address. At this point, the client could STFU and try to make a TCP connection to the server (to ensure connection stability).


If any of the UDP packets don't get through, there's no problem.
The client keeps shouting until it's heard back from the server. If the server misses the client's UDP packet, nothing happens - the client shouts again a few seconds later. If the server hears the client and shouts back, but that packet gets lost, nothing happens; the client just shouts again in a few seconds.

But when the client shouts and the server responds - and the client gets the response - as part of that response, client will now have the server's IP address and will establish a (quieter) TCP/IP connection to the server. Then everything settles down and nobody is shouting any more.


Sure, we could probably just have the server continually broadcasting its presence across the UDP network, and any clients that boot up could just automatically go into listening mode. But it feels like we're making the network unnecessarily "noisy" - since once a client has connected, neither client nor server are using UDP to talk to each other; since clients connecting would only take place right at the very start of a gaming session, it seems unnecessary to have the server shouting it's presence across the network when 99% of the time, nobody will be listening!


Comments

Post a Comment

Popular posts from this blog

Understanding the hall sensor input matrix

Image
 We're using "multiplexing" to read our grid of 16 hall effect sensors. This means we don't need to use 16 individual input pins for reading inputs (which would just about max out an Arduino, and would be too many pins for a NodeMCU ESP8266 type microcontroller). Instead, we split our grid into "rows" and "columns". Then we activate each row, and read the values from each column. This means we need four i/o pins for the rows (outputs) and four i/o pins for the columns (inputs). Let's look a little closer.... Each hall sensor needs power (3.3v-5v supply) a ground connection and has a "floating" signal pin. When a magnet is presented to the sensor, the signal pin is forced "low" (to ground). When the magnet is removed, the signal pin is left floating (note, it is not driven "high" but allowed to "float" to whichever default value we want it to take - the technical term is "open drain" but we don...
Read more

Wireless means one wire less

Image
 Suddenly, the idea of having wifi modules that can automagically connect to a home network seems like a great idea for a multi-part board gaming surface. Instead of having a single, master controller that all the hardware eventually connects to, then using that as a bridge to the app running on a phone/tablet, we can just have the app and the board game pieces talk to each other seamlessly over wifi. And the best thing? One less wire. There'd be no need for a data wire or even for all the board pieces to be physically connected to each other. You could have one over here, one over there, one somewhere else.... So long as there was a consistent means of getting power to the devices, each one could effectively be a stand-alone unit. We could even put a rechargeable battery in each board section - just switch them on, throw them down onto the table, and you're ready to play! Of course, having multiple board sections for a nice large playing area (such as a HeroQuest dungeon or a ...
Read more

Fewer pins = better?

Image
 The idea of losing the data wire, and requiring only power and ground to make our board sections work feels almost revolutionary! Suddenly, we could have board sections on top of buildings (for large, open area wargame type scenarios). But reducing our connectors down to just two pins (instead of three) also means a slight problem - because a two-pin connector isn't symmetrical. And, as we've already discussed, having boards with just two pins can mean all kinds of problems if someone were to rotate the board around, and try to connect incompatible pins together And the answer was as simple as it was obvious. Simply stop trying to make the board panels symmetrical! Don't allow people to rotate the boards to connect them together! In fact, making the board panels in such a way that they could be  rotated only means additional complexity in working out where each square on the board is, in physical space. As the board piece rotates, the physical location in space of our 0,0 ...
Read more