dann an seinen Outputs wieder ausgibt?
dann an seinen Outputs wieder ausgibt?
Wir sind in einer gruppe auf Englisch, so ...
You have to program a bit, but it is possible.
I understand that some of the GPIO pins are regarded as inputs and the others as outputs, and you need that the inputs on machine A will be copied to outputs on machine B, and inputs on machine B to outputs on machine A.
I'd allocate an UDP port on both machines to the channel, and use select() to wait for input to the port, and set the timeout suitably to poll the input pins. If there are changes in the inputs, send an UDP datagram containing the new input state to the other host. If there is a datagram in the socket, copy the contents to the outputs.
-- Tauno Voipio
Could 2 rPi/s on a single LAN *share* an IP, so that for a change of input conditions [you mean a specific signal/bit-stream ?] each of the 2 rPi/s repeats the signal..........
This sounds like multiple rPi/s on a LAN all with the same IP [is THAT possible, with standard protocols?], and each one recognising it's own ID-message, and RE-transmitting the following bitstream, until it recognises an EndOfMessage.
What about the LAN input that the OP wants?
No, not if they will both be active at the same time.
Not enough detail of the requirement has been given here, but here are some thoughts...
There are three ways to do this:
One system monitors the network traffic and copies the traffic stream to all the others.
Use UDP multicast, in which case any number of systems can receive the traffic. Note however that delivery by the network's transport layer (UDP) is not guaranteed, and you might need to implement a packet loss detection and retransmission mechanism in your own higher level protocol.
You communicate with only one system, but the others spy on the network traffic and duplicate the actions. Two problems with this: if one of the other systems misses any packets, it has no way to ask for retransmission; and you would need to connect them with ethernet hubs so they all see all the traffic (and not switches), but hubs haven't been around for some ~15 years now.
You can get an interrupt generated when GPIO pins change, such that a poll() call will return on network input or one of your pins changing (or a timeout if you need that for something else).
-- Andrew Gabriel [email address is not usable -- followup in the newsgroup]
No that is not possible - well it is possible but it won't work because the ARP mechanism assumes one MAC address per IP.
-- Steve O'Hara-Smith | Directable Mirror Arrays C:>WIN | A better way to focus the sun
Note that the poster was not asking for multiple systems to use the same IP, but to have multiple systems that tell eachother what their IP is, so that they can communicate.
Indeed, you can use UDP multicast for that purpose, and then use the address obtained from that multicast for direct communication using any method you like (can just as well be TCP).
No. You cannot have two stations on a lan having the same IP at the same time. It simply won't work with the ARP protocol to resolve the mac addresses on the LAN.
If you want failover you can use HSRP, VRRP, CARP or similar to have one floating ip address served by multiple hosts.
You can have a non-LAN interface, e.g. lo1; as a source of the messages, and route them onto the LAN. This way you can have a reverse multicast; but this is still OK.
This is just a simple matter of programming. I would use TCP, though.
Note that Unknown dog, as usual, has not understood the problem and is going along the wrong track.
The poster did not ask for two devices to have the same address and track the same IP data from another source. What he asked is to have two devices in a LAN that tell eachother which (different, of course) address they have, and then each of them samples 8 inputs, transmits the state to the other, and the other outputs that on 8 outputs. The second device also performs the input function and transmits it to the first, that outputs it.
Kind of an electronic 8-pole cable that operates via LAN. No special tricks required with addresses, only some mechanism to tell the other unit the address to communicate with, a form of autoconfiguration that could be solved with local broadcast or multicast.
On Sat, 25 Oct 2014 02:22:20 +0000 (UTC), Unknown declaimed the following:
As I understand the protocols, IP routing eventually devolves to a MAC address route (IP numbers can change but the MAC connections don't).
Might be doable for UDP packets, but not for TCP -- as the TCP connection would only be made on the "first responder" and the other may eventually time-out when it doesn't get confirmation of a connection.
Even UDP will only work if the packet(s) are sent to all nodes -- which means the nodes are all connected to an old/early-style HUB (no intelligence, all traffic is repeated on all connections) or using original Ethernet coax network. As soon as you get a smart switch or router between nodes, the switch is going to be building a map of MAC address to IP address, and the MAC address will be on a single port. So if two nodes identify to the switch with the same IP, the odds are good that the switch will reject one or the other (possibly alternately if it updates the tables every time a node sends even a keep-alive with the IP).
-- Wulfraed Dennis Lee Bieber AF6VN firstname.lastname@example.org HTTP://wlfraed.home.netcom.com/
Actually Unknown has perfectly understood the question but is trolling as he always does.
Feed the troll and you get more trolling. Please don't feed the troll.
So I wonder why the postings by Unknown get all the followups, while my constructive addition to the thread is completely ignored?
Because he's an expert in trolling and he writes just the things that get people to reply. If you watch he wont reply till the thread starts to cool and then he'll prod it again.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.