I/O tunneln an zweiten Raspi und vice versa?

dann an seinen Outputs wieder ausgibt?

Fragt Ulf

Reply to
Ulf Pr¡mus
Loading thread data ...

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
Reply to
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?

Reply to
Unknown

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]
Reply to
Andrew Gabriel

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 
 Click to see the full signature
Reply to
Ahem A Rivet's Shot

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).

Reply to
Rob

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.

-- mrr

Reply to
Morten Reistad

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.

Reply to
Rob

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 
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/
Reply to
Dennis Lee Bieber

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.

Reply to
mm0fmf

So I wonder why the postings by Unknown get all the followups, while my constructive addition to the thread is completely ignored?

Reply to
Rob

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.

Reply to
mm0fmf

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.