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
If a host with a slow network has two sockets with large send buffers, one socket can prevent the other socket from sending data for a long period of time.
When the network interface can send a packet with fifo queueing (the default), it chooses the packet with the lowest priority. The packet priority is set when the application calls send(), meaning that data from earlier send()s will always be sent before data from later send()s. This can be a problem if the socket has a large send buffer which gets filled by the application. Any other sockets on the host will need to wait for that socket to send all of its packets before the other sockets can send their packets. In extreme cases, this can causes a socket to not send any packets for over 2 minutes. This is an issue with Shadow's implementation of fifo queueing and this issue also applies to UDP sockets.
For example, here we have two sockets on a slow host (up/down bandwidth of 500 Kibps). Each socket is given a 100 MiB send buffer, which we write a total of 10 MiB to. One socket will have all of its data prioritized over the other.
importsocketimportsysimporttimes=socket.socket(socket.AF_INET, socket.SOCK_STREAM)
# set send buffer length of 100 MiBs.setsockopt(socket.SOL_SOCKET, socket.SO_SNDBUF, 100*(1024**2))
s.connect((sys.argv[1], int(sys.argv[2])))
# send 10 MiBsize=10*(1024**2)
buf=b'1'*sizewhilelen(buf) !=0:
num=s.send(buf)
buf=buf[num:]
# try to work around https://github.com/shadow/shadow/issues/3100time.sleep(10)
s.shutdown(socket.SHUT_WR)
assertb''==s.recv(1)
s.close()
If a host with a slow network has two sockets with large send buffers, one socket can prevent the other socket from sending data for a long period of time.
When the network interface can send a packet with fifo queueing (the default), it chooses the packet with the lowest priority. The packet priority is set when the application calls
send()
, meaning that data from earliersend()
s will always be sent before data from latersend()
s. This can be a problem if the socket has a large send buffer which gets filled by the application. Any other sockets on the host will need to wait for that socket to send all of its packets before the other sockets can send their packets. In extreme cases, this can causes a socket to not send any packets for over 2 minutes. This is an issue with Shadow's implementation of fifo queueing and this issue also applies to UDP sockets.For example, here we have two sockets on a slow host (up/down bandwidth of 500 Kibps). Each socket is given a 100 MiB send buffer, which we write a total of 10 MiB to. One socket will have all of its data prioritized over the other.
If we look at the client's pcap, we can see that one of the sockets had a period of ~173 seconds where it didn't send any packets.
It was only able to send packets after the other socket had finished sending all of its packets.
The text was updated successfully, but these errors were encountered: