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
socket.recvfrom result does not contain remote address
datagrams are not delimited on message boundary. For example, a recv(10) will contain data from 2 datagrams if two senders send datagrams of size 5
The UDP_SOCK scheme for keeping track of partially processed datagrams breaks down if there is more than one socket receiving datagrams.
Below is code.py for following tests.
Test 1:
Use the test code and edit bufsize=10,sleeptime=1,timeout=0
On source 1: echo src1 | nc -w 1 -u 192.168.0.99 5500
On source 2: echo src2 | nc -w 1 -u 192.168.0.99 5500
Then the system displays:
datagram from 0.0.0.0:0 Data: b'src1\nsrc2\n'
The messages from two sources are run together (and there
is no information in the address result)
Test 2:
Use the test code and edit bufsize=0,sleeptime=10,timeout=0
On source 1: echo src1 | nc -w 1 -u 192.168.0.99 5500
and wait for the message datagram from 0.0.0.0:0 Data: b'src1\n'
Then withing ten seconds do the next two sends:
On source 1: echo src1 | nc -w 1 -u 192.168.0.99 5500
On source 2: echo src2 | nc -w 1 -u 192.168.0.99 5500
Then the system displays:
datagram from 0.0.0.0:0 Data: b'src1\nsrc2\n'
The messages from two sources are run together (and there
is no information in the address result)
When implementing a fix, a decision has to be made -
what to do if the recv(bufize) is such that the full
datagram will not fit. To match behavior from other systems
it is decided that if the buffer will not hold the complete
datagram, then datagram contents up to the bufsize are
returned and the rest of the datagram is lost.
code.py for tests:
importboardimportbusioimportdigitalioimporttimefromadafruit_wiznet5k.adafruit_wiznet5kimportWIZNET5K#from adafruit_wiznet5k.adafruit_wiznet5k import UDP_SOCKimportadafruit_wiznet5k.adafruit_wiznet5k_socketassocket##SPI0SPI0_SCK=board.GP18SPI0_TX=board.GP19SPI0_RX=board.GP16SPI0_CSn=board.GP17##resetW5x00_RSTn=board.GP20print("datagram test")
# Setup your network configuration below# random MAC, later should change this value on your vendor IDMY_MAC= (0x00, 0x01, 0x02, 0x03, 0x04, 0x05)
IP_ADDRESS= (192,168,0,99) # change to match networkSUBNET_MASK= (255, 255, 255, 0)
GATEWAY_ADDRESS= (192,168,0,1) # change to match networkDNS_SERVER= (8, 8, 8, 8)
led=digitalio.DigitalInOut(board.GP25)
led.direction=digitalio.Direction.OUTPUTethernetRst=digitalio.DigitalInOut(W5x00_RSTn)
ethernetRst.direction=digitalio.Direction.OUTPUT# For Adafruit Ethernet FeatherWingcs=digitalio.DigitalInOut(SPI0_CSn)
# For Particle Ethernet FeatherWing# cs = digitalio.DigitalInOut(board.D5)spi_bus=busio.SPI(SPI0_SCK, MOSI=SPI0_TX, MISO=SPI0_RX)
# Reset W5500 firstethernetRst.value=Falsetime.sleep(1)
ethernetRst.value=Truetime.sleep(0.1)
# Initialize ethernet interface with DHCPeth=WIZNET5K(spi_bus, cs, is_dhcp=False, mac=MY_MAC, debug=False)
eth.ifconfig= (IP_ADDRESS, SUBNET_MASK, GATEWAY_ADDRESS, DNS_SERVER)
print("Chip Version:", eth.chip)
print("MAC Address:", [hex(i) foriineth.mac_address])
print("My IP address is:", eth.pretty_ip(eth.ip_address))
# init socket libsocket.set_interface(eth)
# test parametersbufsize=0# set to 0 or some non-zero value to test different situationssleeptime=10# set large to test case of datagrams from two sources run togethertimeout=0# set depending on testsock=socket.socket(socket.AF_INET,socket.SOCK_DGRAM) # Allocate socket for the serverport=5500sock.bind((None,port))
print("Listening for datagram on port {}".format(port))
sock.settimeout(timeout)
whileTrue:
withsock:
whileTrue:
led.value=notled.valuetime.sleep(sleeptime)
data, addr=sock.recvfrom(bufsize)
ifdata:
print("datagram from {}:{} Data: {}".format(addr[0], addr[1], data))
elifbufsize:
# timeout is not relevant if bufize==0, since recvfrom# returns immediately if no dataprint("No data, timeout")
The text was updated successfully, but these errors were encountered:
There are three issues:
socket.recvfrom result does not contain remote address
datagrams are not delimited on message boundary. For example, a recv(10) will contain data from 2 datagrams if two senders send datagrams of size 5
The UDP_SOCK scheme for keeping track of partially processed datagrams breaks down if there is more than one socket receiving datagrams.
Below is code.py for following tests.
Test 1:
Use the test code and edit bufsize=10,sleeptime=1,timeout=0
On source 1:
echo src1 | nc -w 1 -u 192.168.0.99 5500
On source 2:
echo src2 | nc -w 1 -u 192.168.0.99 5500
Then the system displays:
datagram from 0.0.0.0:0 Data: b'src1\nsrc2\n'
The messages from two sources are run together (and there
is no information in the address result)
Test 2:
Use the test code and edit bufsize=0,sleeptime=10,timeout=0
On source 1:
echo src1 | nc -w 1 -u 192.168.0.99 5500
and wait for the message datagram from 0.0.0.0:0 Data: b'src1\n'
Then withing ten seconds do the next two sends:
On source 1:
echo src1 | nc -w 1 -u 192.168.0.99 5500
On source 2:
echo src2 | nc -w 1 -u 192.168.0.99 5500
Then the system displays:
datagram from 0.0.0.0:0 Data: b'src1\nsrc2\n'
The messages from two sources are run together (and there
is no information in the address result)
When implementing a fix, a decision has to be made -
what to do if the recv(bufize) is such that the full
datagram will not fit. To match behavior from other systems
it is decided that if the buffer will not hold the complete
datagram, then datagram contents up to the bufsize are
returned and the rest of the datagram is lost.
code.py for tests:
The text was updated successfully, but these errors were encountered: