How to communicate the raspberry pi and the pc with one another via wireless?

Question

How do I communicate the raspberry pi and the pc with one another via wireless? Like for example the raspberry will send maybe a e.g pulse as codes for the pc (pc shall convert the signal for it to understand what the raspberry pi is sending ) and send back some info to the raspberry pi

Answer 1

How do I communicate the raspberry pi and the pc with one another via wireless?

Presuming both systems have appropriate hardware available to them, this communication is governed by the Internet Protocol. Protocols are necessary to determine things like:

• Who is this message for? Networks are decentralized, meaning they do not have a central authority. While your router maybe what makes it possible, its role is primarily to channel communication into and out of the network, and to serve as a physical rely from one connected system to another. However, this relying is not sorting -- it doesn't decide where a message should go (except if it needs to pass it to the outside), it goes to everyone. On wifi it's easy to understand how that's inevitable; on ethernet, although wires are used, the situation is the same.

  So the address allows your system to decide which messages are for it and which aren't.

• Who is this message from? This is to ensure replies to the message go to the right place. Note that's for convenience and not security, since a system can lie about its IP address.

• How big is this message? This is necessary since the recipient reads messages in a serial stream, one after the other, and needs to know when one ends and another begins.

That's IP in a nutshell. Networking protocols exist in layers like onion skin, each layer wrapping the information in the next; the information in the IP layer is what allows one system to get a message to another. The next layer of information is (almost always) TCP or UDP, which govern some things about the how messages are packaged for transmission and includes a port number, which is an address internal to the system, since the system may have various concurrent but unrelated channels of communication going on via the same physical connection.

IP plus TCP or UDP details are handled by the OS kernel. The point at which your program receives a message is the point at which the kernel has decided this message is for this system (because of IP address) and for your program in particular (because of port number). However, you do have to have a basic understanding of IP addresses and port numbers because you do have to manually address your messages to someone, at least in establishing a channel of communication. How you do exactly that depends on what language you want to use, etc.

The Client-Server Model of Communication

The other important thing to understand about networking, besides addresses and port numbers, is the client-server model. A server is a program that waits for messages addressed to it from anyone, anywhere (it does not have to accept them, however). A client is a program that sends a message to a server, and once such a channel of communication is established, can then receive messages from that server.

A client cannot receive messages arbitrarily from anyone. It must initiate communication, with a server. However, servers can rely messages between multiple clients. Web browsers are network clients; they communicate directly only with web servers, not other browsers.

A server can establish communication with another server, although it does so as a client, using client style mechanisms. This is sometimes called "peer-to-peer" networking since it can involve two copies of exactly the same program on two different systems.

What's in a Message?

There are protocols that are wrapped within TCP (or UDP) within IP. For example, the WWW uses the HTTP protocol. Unlike the previous layers, these are implemented completely in userspace, meaning your program has to interpret the details. The idea of a "protocol" is to provide a set of rules about how a message is structured and what it means, such as:

pulse as codes for the pc (pc shall convert the signal for it to understand what the raspberry pi is sending ) and send back some info to the raspberry pi

Except you aren't working with "pulses", you are working with streams of bits. But you can make whatever rules you want up here. Protocols usually work via headers at the beginning of the message, though often there won't be any message besides the header (if there is, it may contain another header, for another layered protocol, which is exactly how all the protocols discussed here work).

A common element of userspace protocols is something to do with length, since the length fields used in the IP/TCP/UDP headers won't be useful to you (they may include the length of header data not in the message you deal with, and involve the system breaking your messages into chunks). So a really simple protocol could be used for relying text messages in a specific encoding; the only header data required being (e.g.) the first 32-bits as an integer indicating the number of bytes or characters in the message.¹ If the encoding (e.g., ASCII, UTF-8, UTF-16) isn't specifically established in advance ("this protocol uses ASCII only"), then you'd also need something to indicate that so these bytes can be translated into text correctly.

You could implement a simple protocol that doesn't require any header or meta-information. For example, every message is 1 KB of data, padded with zeros if necessary. You could also implement one that uses only a structured header with no additional content; for example, every message is a four byte code (I think that is something like what you are after).

---

^{1. Note, again, you can't simply "keep reading until the message is over" because there is no way to say when it is over unless you know how long it was supposed to be to start with.}