You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Implement ICMP sockets that are somewhat equivalent to linux IPPROTO_ICMP sockets. Much of the implementation may be similar to the other socket types, but there will likely be a few crucial differences.
Icmpv4Socket::accepts is determined only by the source IP and destination IP. This means that if two separate icmp sockets sent from the same source to the same destination, things would get mixed up. Without access to the IP id, I don't see a way around this. If this direction is taken, a should_fail test with a note and an issue to make sure we don't lose track of this would be nice.
The send and send_slice methods should be somewhat similar to the current udp implementation where the destination address is an arg.
It might be more readable to use a recv_from method that takes the address to receive packets from as an arg instead of the typical recv function. If we really want to stick to recv instead of recv_from we could keep the destination that will be used by Icmpv4Socket::accepts from the previous send.
Implement ICMP sockets that are somewhat equivalent to linux
IPPROTO_ICMP
sockets. Much of the implementation may be similar to the other socket types, but there will likely be a few crucial differences.Icmpv4Socket::accepts
is determined only by the source IP and destination IP. This means that if two separate icmp sockets sent from the same source to the same destination, things would get mixed up. Without access to the IP id, I don't see a way around this. If this direction is taken, ashould_fail
test with a note and an issue to make sure we don't lose track of this would be nice.send
andsend_slice
methods should be somewhat similar to the current udp implementation where the destination address is an arg.recv_from
method that takes the address to receive packets from as an arg instead of the typicalrecv
function. If we really want to stick torecv
instead ofrecv_from
we could keep the destination that will be used byIcmpv4Socket::accepts
from the previous send.Related to: #50
The text was updated successfully, but these errors were encountered: