cx_freeze frozen executive introduces WinError 10049

[KipCarter]

I am building a matching set of utilities to provide text transmission between two computers on the same network.

I started with sample code from a python cookbook. There is a sender and receiver code base that function in their role.

I have made some improvements and modifications to the code that make it more useful to the environment where this is to be used.

The code works perfectly when it is functioning strictly on the Python 3.6 interpreter.

When I freeze it with cx_freeze, both companion programs build fine. The strange thing is that that sender executes works perfectly while the receiver bombs out.

Here is the Traceback for your reference:

Error:
Traceback (most recent call last):
  File "C:\Python\lib\site-packages\cx_Freeze\initscripts\__startup__.py", line 40, in run
    module.run()
  File "C:\Python\lib\site-packages\cx_Freeze\initscripts\Console.py", line 37, in run
    exec(code, {'__name__': '__main__'})
  File "Receiver.py", line 24, in <module>
OSError: [WinError 10049] The requested address is not valid in its context

Below are both my sender.py and receiver.py. The portion that is breaking in the receiver executable is identical to what is used in the sender (except for IP address, which is valid).

Any insight in this problem would be greatly appreciated and feel free to use this code for your own purpose. As I said, the py version works like a charm.

Receiver.py - Written for Python 3.6 windows

import os
import sys
import subprocess
from socket import *

subprocess.call("cls", shell=True)

theargis = ''

if len(sys.argv) > 1:
    theargis +=str(sys.argv[1])

if theargis > '':
    host = theargis
    print ("Using Client Address of: " + theargis)
else:
    host = "53.68.241.25"
    print ("Using Default Address!")

port = 13000
buf = 1024
addr = (host, port)
UDPSock = socket(AF_INET, SOCK_DGRAM)
UDPSock.bind(addr)

print ("Waiting to receive messages...")

while True:
    (data, addr) = UDPSock.recvfrom(buf)
    print ("Production number: " + data.decode("utf-8"))
    if data.decode("utf-8").upper() == "EXIT":
        break

UDPSock.close()
os._exit(0)

Sender.py - Written for Python 3.6 windows

import os
import sys
import subprocess
from socket import *

subprocess.call("cls", shell=True)

theargis = ''

if len(sys.argv) > 1:
    theargis +=str(sys.argv[1])

if theargis > '':
    host = theargis
    print ("Using Server Address of: " + theargis)
else:
    host = "53.68.240.47" 
    print ("Using Default Address!")

port = 13000
addr = (host, port)
UDPSock = socket(AF_INET, SOCK_DGRAM)

while True:
    data = input("Enter message to send or type 'EXIT': ")
    bytes = data.encode()
    UDPSock.sendto(bytes, addr)
    if data.upper() == "EXIT":
        break

UDPSock.close()
os._exit(0)

[snippsat]

Try change host to localhost on both,then build and it should work.
I guess there can be a difference after you build to .exe on how OS is looking at external IP.
If your machine is not aware of this IP,you will get this message.

Your code running from two .exe files.
Using Pyinstaller(Recommended),and Python 3.7.
Build commands.

pyinstaller --onefile Receiver.py
pyinstaller --onefile Sender.py

[KipCarter]

Try change host to localhost on both,then build and it should work.
I guess there can be a difference after you build to .exe on how OS is looking at external IP.
If your machine is not aware of this IP,you will get this message.

The problem is not building the exe, which works fine. In addition, there is an issue if I want to communicate another machine if I am binding to localhost. The other thing that would puzzle me in this approach is the fact that sender.exe works find and is able to send to recever.py on another machine, while receiver.exe (with the exact same statement) blows up.

I am willing to try the localhost address (and I will) but, at first blush, it sounds like an exercise in futility if my goal is to talk external to my receiving device.


Thanks,
Kip...

---

Follow up...

snippsat,
I went ahead and built receiver.exe using a localhost address. When I ran it on my machine it opened properly (unlike my prior version that was pointing to the sender).

I was in hopes that the listing was just to the port and the IP address in the binding was not significant, however when sending to the new receiver; no data was received.

Thanks,
Kip...

[KipCarter]

I have concluded that this issue is resolvable in the current environment. There is nothing wrong with the code, it is perfectly fine. What the problem focuses back to is that the network has a firewall rule that prevents UDP data from crossing the firewall boundary in one direction.

For that reason the machine in question could not use the Receiver while it was able to be the sender just fine.

Regards,
Kip...