LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Timeout on reception for UDP fragmented packets

Hi,

I developed an application in LabView 2020 SP1 which communicates over ethernet with other systems using UDP packets.

Some of the replies that my software should recive excede the MTU limit (1500 bytes), so when I analyze the network communication with wireshark, I see that these packets are splitted in some fragments that are automatically fused into the original UDP packet before fragmentation.

The communication for packets whose size is lower then MTU I have no issue and all works correctly.

The problem I'm having is that my software can't see any reply by the other systems when these packets are fragmented (reception has timeout error).

I also made some tests by making the same messages exchanges on the same machine (on localhost), in order to avoid IP fragmentation, and in this case my software is able to recive data without any problem.

What could cause such behaviour in my software?

Here attached the picture of the vi that sends a query and then waits for the reply.

 

vi_tx_rx.PNG

0 Kudos
Message 1 of 3
(1,039 Views)

Accordi g the attached Image, the communication steps are:

1. Open transmission socket

2. Open reception socket

3. Compose message to send

4. Send message on transmission socket

5. Wait for reply on receive socket

6. Close sockets

 

For step 5 I tried to use expected message size both a bigger size (like in the image) and the exact size, but in both cases the result is a timeout on reception. 

0 Kudos
Message 2 of 3
(1,004 Views)

It is impossible to debug an image, especially since we have no idea what the values are.

Is this a subVI or the caller running in "run continuous" mode. If it is a subVI, how is it called? Can you attach your VI instead?

 

Why do you need to read the same global three times in parallel? Wouldn't it be more reasonable to read it once and branch the wire? Are you really constantly opening and closing the same connection? Why do you need tow different connections in parallel? Send and receive should probably use the same connection, just correctly define local and remote ports.

 

 

0 Kudos
Message 3 of 3
(968 Views)