Uncategorized

OSI 7 layer model

0

I’m setting up a network of rpi’s for multiroom audio purposes. I want all the rpis to be connected to each other by using tcp sockets (I need to be sure that messages are sent and received) so that they may interact easely.

These communications will not be used to transfer audio content as I use snapcast for this (and it perfectly suits my needs).

My problem concerns the initiating of rpis network. I want all the rpis connected to the same wifi network and running the same python program to first, discover themselves and then, connect to each other without hardcoding names/adresses of other rpis in each device.

For the moment, I’ve coded a small library which combines udp for advertising/discovering and TCP for safe messaging, but it does not work perfectly (I face random disconnection after a few days of use and I’m not an expert in udp/tcp networking).

Instead of using my in-house library, I wonder wether python libraries doing the same job (or close) exist and any help/ideas would be appreciated.

put on hold as off-topic by goldilocks 14 hours ago

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • “This question does not appear to be specific to the Raspberry Pi within the scope defined in the help center.” – goldilocks

If this question can be reworded to fit the rules in the help center, please edit the question.

  • From time to time I read about random Rpi freezing for unknown reasons. One reason of freezing is that Rpi resources are used up. And one of the many reasons of resources using up is about sockets, that too many sockets have been created, garbage sockets no long used are not collected. One solution or get around is to install a watch dog timer which reboots the system when detecting a freeze. So you might like to install a watchdog timer and see if problem disappears. ( raspberrypi.stackexchange.com/questions/99584/… ) – tlfong01 17 hours ago    
  • 1
    This seems to be a nice idea but in my cases, unresponsive rpis (via ssh or tcp/udp) are still responsive locally (by using buttons, rotaries and lcd display via gpio). As a consequence, The rpi system might still be itself responding. I’m starting to consider periodic reboot of the rpis each night to solve my problems but I would prefer to use a appropriated wireless messaging library – M. Miguel-Brebion 17 hours ago
  • @tlfong01 Suggesting it is too many open sockets and to try setting up a watchdog in this case is like suggesting it may be caused by cosmic rays affecting the processor, and to rule this out the OP should try magnetic shielding. Is it possible? Sure. Is it worth knowing it can cause a problem? Sure. Is it worth active time-wasting as a possible cause at this point? No. I don’t see any indication that the OP is making tens of thousands of TCP connections. – goldilocks 14 hours ago
  • “I wonder wether python libraries doing the same job” -> Raspbian runs avahi by default, I think, which is a zeroconf implementation. There are also implementation in pure python (search “python zeroconf”), but if you give each pi a unique hostname you should just be able to get the addresses that way. In any case, this isn’t a pi specific issue and you would be better off asking about it on our larger parent site, Stack Overflow.– goldilocks 14 hours ago
  • “I face random disconnection after a few days of use and I’m not an expert in udp/tcp networking” -> You need to deal with this in code; if a connection closes unexpectedly it should be re-established. – goldilocks14 hours ago
  • @goldilocks, well, my comments about socket is just an example. There might be 101 cases of resources using up. There may be other external causes, like cosmic ray, sun black spots, rpi getting old etc. What I was suggesting is that a watchdog timer can be an universal, one size fits all get around. – tlfong01 13 hours ago   
  • @M. Miguel-Brebion, I see, so your rpi is not freezing up. And as you say, if the problem arises a couple of days (but not weeks, or hours), then a watchdog timer is an ounce of no harm prevention, better than a ton of cure, or before you find a cure. – tlfong01 13 hours ago   
  • @tlfong01 To be fair I don’t see any indication that the OP isn’t making tens of thousands of TCP connections (left open in a loop, etc., dunno what python GC does there). I think more hunkering down and debugging is in order or, the OP is looking for a high level message passing library to ditch his/her possibly faulty code (wise). I am sure there are many such things available in python, but you probably want to focus more on the nature of the messages to be passed to find something appropriate. – goldilocks 12 hours ago
  • Ah,I guess there is some big misunderstanding here. I must first confess that I have almost zero experience in writing C/C++/python program in low level communications, using sockets etc. Most of my projects are at the level of UART/I2C/SPI. In other words I have only a vague idea of what the OP is doing, writing python programs using TCP sockets. What interested me is that his problem occurs after a couple of days, not weeks, not hours. And this time frames fits the universal get around I know, using watchdog timer, for whatever hardware or software causes, … / to continue, … – tlfong01 11 hours ago   
  • Sockets aren’t a lower level entity than the UART interface, they are parallel. I think a problem with the watchdog timer approach is that it most likely just glosses over programming errors. Which is not to say it is a bad idea to have one, but it is a bad idea to consider triggering it a part of normal operations. – goldilocks11 hours ago
  • @goldilocks, OK so socket is at the same level of UART. So you now you know I am ignorant in sockets. So I wrongly thought that sockets are TCP level which uses CAT5 cables. UART uses DB9 cables. I can mess around DB9 cables and use scope to look at the waveforms. I never mess around CAT5 cable and don’t know how to look at their waveforms. I usually play with UART at 9600 baud. But I know Ethernet are 2.6G to 5GHz and I don’t know how to use my cheap scope to look at the signals. So I wrongly thought that higher level is slow, and low level is fast. Need google to correct myself. – tlfong01 10 hours ago   
  • @goldilocks, Actually which level is which depends on the model. I vaguely remember the IEEE model I learnt last century has 7 levels. The top level is application level. Down one or two are the internet guys, TCP, UDP. In other words UART, SPI, and I2C which I think is top level applications, so are NOT in the same level as TCP and UDP. In other words, saying that UART and TCP (sockets) are at the same layer is incorrect and misleading. – tlfong01 10 secs ago   Edit   

Categories: Uncategorized

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: