Aprial 30th Monday (四月 三十日 月曜日)

  ARP - Although this is a protocol that lies underneath IPv4, and not a user application, ARP broadcasts
a request on the local subnet that says, "Will the system with an IP address of a.b.c.d please identify
yourself and tell me your hardware address?" ARP uses link-layer broadcast, not IP-layer, but is an example
of a use of broadcasting.

  DHCP - The client assumes a server or relay is on the local subnet and sends its request to the broadcast
address (often 255.255.255.255 since the client doesn't yet know its IP address, its subnet mask, or the
limited broadcast address of the subnet).


Broadcast Addresses

  If we denote an IPv4 address as {subnetid, hostid}, where subnetid represents the bits that are covered
by the network mask (or the CIDR prefix) and hostid represents the bits that are not, then we have two types
of broadcast addresses. We denote a field containing all one bits as -1.

  1. Subnet-directed broadcast address: {subnetid, -1} - This addresses all the interfaces on the specified subnet.
For example, if we have the subnet 192.168.42/24, then 192.168.42.255 would be the subnet-directed broadcast
address for all interfaces on the 192.168.42/24 subnet.

  Normally, routers do not forward these broadcasts.  The router receives a unicast IP datagram on the 192.168.123/24
subnet with a destination address of 192.168.42.255 (the subnet-directed broadcast address of another interface).
The router normally does not forward the datagram on to the 192.168.42/24 subnet. Some systems have a configuration
option that allows subnet-directed broadcasts to be forwarded.

  Note:  Forwarding subnet-directed broadcasts enables a class of denial-of-service attacks called "amplification"
attacks; for instance, sending an ICMP echo request to a subnet-directed broadcast address can cause multiple replies
to be sent for a single request. Combined with a forged IP source address, this results in a bandwidth utilization
attack against the victim system, so it's advisable to leave this configuration option off.

  2.  Limited broadcast address: {-1, -1, -1} or 255.255.255.255 - Datagrams destined to this address must never be
forwarded by a router.

  255.255.255.255 is to be used as the destination address during the bootstrap process by applications such as BOOTP
and DHCP, which do not yet know the node's IP address.  Most hosts allow this (assuming the process has set the SO_BROADCAST
socket option) and convert the destination address to the subnet-directed broadcast address of the outgoing interface.
It is often necessary to access the datalink directly to send a packet to 255.255.255.255.

  What does a multihomed host do when the application sends a UDP datagram to 255.255.255.255? Some systems send
a single broadcast on the primary interface (the first interface that was configured) with the destination IP address
set to the subnet-directed broadcast address of that interface.  Other systems send one copy of the datagram out
from each broadcast-capable interface.

  The subnet address of the Ethernet is 192.168.42/24 with 24 bits in the network mask, leaving 8 bits for the host ID.
The application on the left host calls sendto on a UDP socket, sending a datagram to 192.168.42.3, port 7433. The UDP
layer prepends a UDP header and passes the UDP datagram to the IP layer. IP prepends an IPv4 header, determines
the outgoing interface, and in the case of an Ethernet, ARP is invoked to map the destination IP address to
the corresponding Ethernet address: 00:0a:95:79:bc:b4. The packet is then sent as an Ethernet frame with that
48-bit address as the destination Ethernet address. The frame type field of the Ethernet frame will be 0x0800,
specifying an IPv4 packet. The frame type for an IPv6 packet is 0x86dd.

  The Ethernet interface on the host in the middle sees the frame pass by and compares the destination Ethernet
address to its own Ethernet address 00:04:ac:17:bf:38). Since they are not equal, the interface ignores the frame.
With a unicast frame, there is no overhead whatsoever to this host. The interface ignores the frame.

  The Ethernet interface on the host on the right also sees the frame pass by, and when it compares the destination
Ethernet address with its own Ethernet address, they are equal. This interface reads in the entire frame, probably
generates a hardware interrupt when the frame is complete, and the device driver reads the frame from the interface
memory. Since the frame type is 0x0800, the packet is placed on the IP input queue.

  When the IP layer processes the packet, it first compares the destination IP address (192.168.42.3) with all
of its own IP addresses. Since the destination address is one of the host's own IP addresses, the packet is accepted.

  The IP layer then looks at the protocol field in the IPv4 header, and its value will be 17 for UDP. The IP datagram
is passed to UDP.

  The UDP layer looks at the destination port (and possibly the source port, too, if the UDP socket is connected),
and in our example, places the datagram onto the appropriate socket receive queue. The process is awakened, if necessary,
to read the newly received datagram.

  The key point in this example is that a unicast IP datagram is received by only the one host specified by the destination
IP address. No other hosts on the subnet are affected.

  When the host on the left sends the datagram, it notices that the destination IP address is the subnet-directed broadcast
address and maps this into the Ethernet address of 48 one bits: ff:ff:ff:ff:ff:ff. This causes every Ethernet interface on
the subnet to receive the frame. The two hosts on the right of this figure that are running IPv4 will both receive the frame.
Since the Ethernet frame type is 0x0800, both hosts pass the packet to the IP layer. Since the destination IP address matches
the broadcast address for each of the two hosts, and since the protocol field is 17 (UDP), both hosts pass the packet up to UDP.

  The host on the right passes the UDP datagram to the application that has bound UDP port 520. Nothing special needs to be
done by an application to receive a broadcast UDP datagram: It just creates a UDP socket and binds the application's port number
to the socket. (We assume the IP address bound is INADDR_ANY, which is typical.)

  On the host in the middle, no application has bound UDP port 520. The host's UDP code then discards the received datagram.
This host must not send an ICMP "port unreachable," as doing so could generate a broadcast storm: a condition where lots of
hosts on the subnet generate a response at about the same time, leading to the network being unusable for a period of time.
In addition, it's not clear what the sending host would do with an ICMP error: What if some receivers report errors and others
don't?

  a unicast address identifies a single IP interface, a broadcast address identifies all IP interfaces on the subnet, and
a multicast address identifies a set of IP interfaces. Unicasting and broadcasting are the extremes of the addressing spectrum
(one or all) and the intent of multicasting is to allow addressing something in between. A multicast datagram should be received
only by those interfaces interested in the datagram, that is, by the interfaces on the hosts running applications wishing to
participate in the multicast group. Also, broadcasting is normally limited to a LAN, whereas multicasting can be used on
a LAN or across a WAN.


IPv4 Class D Addresses

  The low-order 28 bits of a class D address form the multicast group ID and the 32-bit address is called the group address.
Considering just the IPv4 mapping, the high-order 24 bits of the Ethernet address are always 01:00:5e. The next bit is always 0,
and the low-order 23 bits are copied from the low-order 23 bits of the multicast group address. The high-order 5 bits of the
group address are ignored in the mapping. This means that 32 multicast addresses map to a single Ethernet address: The mapping
is not one-to-one.

  The low-order 2 bits of the first byte of the Ethernet address identify the address as a universally administered group address.
Universally administered means the high-order 24 bits have been assigned by the IEEE and group addresses are recognized and handled
specially by receiving interfaces.

  There are a few special IPv4 multicast addresses:

  1. 224.0.0.1 is the all-hosts group. All multicast-capable nodes (hosts, routers, printers, etc.) on a subnet must join this
group on all multicast-capable interfaces. (We will talk about what it means to join a multicast group shortly.)

  2. 224.0.0.2 is the all-routers group. All multicast-capable routers on a subnet must join this group on all multicast-capable
interfaces.

  The range 224.0.0.0 through 224.0.0.255 (which we can also write as 224.0.0.0/24) is called link local. These addresses are
reserved for low-level topology discovery or maintenance protocols, and datagrams destined to any of these addresses are never
forwarded by a multicast router.


IPv6 Multicast Addresses

  The high-order byte of an IPv6 multicast address has the value ff. The low-order 32 bits of the group address are copied into
the low-order 32 bits of the Ethernet address. The high-order 2 bytes of the Ethernet address are 33:33. The low-order two bits
of the first byte of the Ethernet address specify the address as a locally administered group address. Locally administered means
there is no guarantee that the address is unique to IPv6.  Locally administered means there is no guarantee that the address is
unique to IPv6. There could be other protocol suites besides IPv6 sharing the network and using the same high-order two bytes of
the Ethernet address.

  The low-order two bits of the first byte of the Ethernet address specify the address as a locally administered group address.
Locally administered means there is no guarantee that the address is unique to IPv6. There could be other protocol suites besides
IPv6 sharing the network and using the same high-order two bytes of the Ethernet address. As we mentioned earlier, group addresses
are recognized and handled specially by receiving interfaces.

  There are a few special IPv6 multicast addresses:

  1. ff01::1 and ff02::1 are the all-nodes groups at interface-local and link-local scope. All nodes (hosts, routers, printers,
etc.) on a subnet must join these groups on all multicast-capable interfaces. This is similar to the IPv4 224.0.0.1 multicast
address. However, since multicast is an integral part of IPv6, unlike IPv4, this is not optional.

  Although the IPv4 group is called the all-hosts group and the IPv6 group is called the all-nodes group, they serve the same
purpose. The group was renamed in IPv6 to make it clear that it is intended to address routers, printers, and any other IP
devices on the subnet as well as hosts.


  2. ff01::2, ff02::2 and ff05::2 are the all-routers groups at interface-local, link-local, and site-local scopes. All routers
on a subnet must join these groups on all multicast-capable interfaces. This is similar to the IPv4 224.0.0.2 multicast address.

  IPv6 multicast addresses have an explicit 4-bit scope field that specifies how "far" the multicast packet will travel. IPv6
packets also have a hop limit field that limits the number of times the packet is forwarded by a router. The following values
have been assigned to the scope field:

  1: interface-local
 
  2: link-local
 
  4: admin-local
 
  5: site-local
 
  8: organization-local
 
  14: global
 
  The remaining values are unassigned or reserved. An interface-local datagram must not be output by an interface and a link-local
datagram must never be forwarded by a router. What defines an admin region, a site, or an organization is up to the administrators
of the multicast routers at that site or organization. IPv6 multicast addresses that differ only in scope represent different groups. 

源码来自:https://pan.quark.cn/s/a4b39357ea24 ### 操作指南:洗衣机使用方法详解#### 1. 启动与水量设定- **使用方法**:使用者必须首先按下洗衣设备上的“启动”按键,同时依据衣物数量设定相应的“水量选择”旋钮(高、中或低水量)。这一步骤是洗衣机运行程序的开端。- **运作机制**:一旦“启动”按键被触发,洗衣设备内部的控制系统便会启动,通过感应器识别水量选择旋钮的位置,进而确定所需的水量高度。- **技术执行**:在当代洗衣设备中,这一流程一般由微处理器掌管,借助电磁阀调控进水量,直至达到指定的高度。#### 2. 进水过程- **使用说明**:启动后,洗衣设备开始进水,直至达到所选的水位(高、中或低)。- **技术参数**:水量的监测通常采用浮子式水量控制器或压力感应器来实现。当水位达到预定值时,进水阀会自动关闭,停止进水。- **使用提醒**:务必确保水龙头已开启,并检查水管连接是否牢固,以防止漏水。#### 3. 清洗过程- **使用步骤**:2秒后,洗衣设备进入清洗环节。在此期间,滚筒会执行一系列正转和反转的动作: - 正转25秒 - 暂停3秒 - 反转25秒 - 再次暂停3秒- **重复次数**:这一系列动作将重复执行5次,总耗时为280秒。- **技术关键**:清洗环节通过电机驱动滚筒旋转,利用水流冲击力和洗衣液的化学效果,清除衣物上的污垢。#### 4. 排水与甩干- **使用步骤**:清洗结束后,洗衣设备会自动进行排水,将污水排出,然后进入甩干阶段,甩干时间为30秒。- **技术应用**:排水是通过泵将水抽出洗衣设备;甩干则是通过高速旋转滚筒,利用离心力去除衣物上的水分。- **使用提醒**:...
代码下载地址: https://pan.quark.cn/s/c289368a8f5c 在安卓应用开发领域,构建一个高效且用户友好的聊天系统是一项核心任务。 为了协助开发者们迅速达成这一目标,本文将分析几种常见的安卓聊天框架,并深入说明它们的功能特性、应用方法及主要优势。 1. **环信(Easemob)** 环信是一个专为移动应用打造的即时通讯软件开发套件,涵盖了文本、图片、语音、视频等多种消息形式。 通过整合环信SDK,开发者能够迅速构建自身的聊天平台。 环信支持消息内容的个性化定制,能够应对各种复杂的应用场景,并提供多样的API接口供开发者使用。 2. **融云(RongCloud)** 融云作为国内领先的IM云服务企业,提供了全面的聊天解决方案,包括一对一交流、多人群聊、聊天空间等。 融云的突出之处在于其稳定运行和高并发处理性能,以及功能完备的后台管理工具,便于开发者执行用户管理、消息发布等操作。 再者,融云支持多种消息格式,如位置信息、文件传输、表情符号等,显著增强了用户聊天体验。 3. **Firebase Cloud Messaging(FCM)** FCM由Google提供的云端消息传递服务,可达成安卓设备与服务器之间的即时数据交换。 虽然FCM主要应用于消息推送,但配合Firebase Realtime Database或Firestore数据库,开发者可以开发基础的聊天软件。 FCM的显著优势在于其全球性的推送网络,保障了消息能够及时且精确地传输至用户。 4. **JMessage(极光推送)** 极光推送是一款提供消息发布服务的软件开发工具包,同时具备基础的即时通讯能力。 除了常规的文字、图片信息外,极光推送还支持个性化消息,使得开发者能够实现更为复杂的聊天功能。 此...
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值