Why is my UDP saying it is connected when it is not?

My issue is is that my UDP client is reporting that it is connected when I have nothing on the network. I'm trying to connect to a PLC module with IP 10.10.10.10 at port 7775 from a computer port of 7777. The Connect() function from the client is working, even though there is no Ethernet or wireless connection turned on.

The core of my problem revolves around my connection code I believe

Public Sub Connect()
    Try
        If (plcType = 0) Then
            udpClient = New UdpClient(7777)
            udpClient.Client.Connect(IPAddress, port)
            SendCommand("ME")
        End If
    Catch
        MsgBox("Could not connect to the controller, please check IP address." & vbCrLf & Err.Description)
        'Connect()
    End Try
End Sub

If I insert a break point after the Connect() command I get extremely strange behavior. After the break point is hit if I look into udpClient.Client's properties it says it is connected, but if I leave those properties and then look at it again it will suddenly change and say it is not connected and the program will correctly read that it is not connected after that point.

This issue only appeared After I connected a second computer and attempted to run the same program on it to the same device. Neither computer can correctly talk to the device anymore, that I can understand, but I can't understand why one of my computers believes that it is talking to the device when it clearly isn't. Thank you for any help.

Update: Any connection available will trigger this condition, only if all networks are disable or disconnected will it behave as expected. However, it is still reporting as connected when there is no device on the network of that IP.

Solution

So @CodeCaster is right saying that "UDP has no notion of being connected". UDP is a connectionless fire-and-forget protocol. When you send a datagram, you have no guarantee it will reach its destination.

Different "connect" operations that are available across a multitude of languages merely mean "ok, we'll use this socket for talking to this specific address and port". This knowledge does not translate to packets being sent over the network. It is a local thing that allows you to use send function instead of sendto.

If you want to know if there's a device on your network listening to a specific IP and UDP port, then you're going to need your own synchronizing mechanism. The protocol does not support that out of the box. So examples are:

Heartbeat. Let your remote peer send a special multicast message every 5 seconds. If you haven't received a heartbeat message in 15 seconds, assume the remote peer is down. Adjust numbers at your own discretion.
Ping-pong, or echo request - echo response. Periodically send a special datagram to the remote peer and expect a response.
Handshakes, acknowledges, retries... The more robust channel you need, the more it is going to remind TCP. This is a kind of a sign to switch protocols!