I am having trouble getting jit.net.recv to connect remotely from a jit.net.send on another machine in Max 7.2.2 on OS X 10.11.5. Port binding does not work, although when I attempt to change jit.net.recv's attributes I tend to get one frame from the video source before it stops working.
Crappy, slow network connection is partially to blame in my case. After blindly port hunting for something that wasn't bound (7480, but I don't ever remember it being this difficult to find an open port while doing OSC stuff??), and shrinking down my webcam resolution to unreasonably tiny (320x240), and lowering the metro framerate (40ms), I got something that had ~12sec latency.
Then, when I tried switching to an ad-hoc WiFi configuration or using a crossover cable, that same port was bound again and hunting for a new one turned up nothing.
Something about Max's ability to bind and hold onto a port for TCP with these two objects is messed up in the newest versions of Max 7.
I just tried a udpsend/udpreceive test and then a mxj.net.send/mxj.send.recv pair with the same ports (7474 first, then another test with 8000) and they both worked fine. So the problem is with jit.net.recv specifically. Running everything in 64-bit and 32-bit.
This default port of 7474 is being used elsewhere as of Max 7 (sorry about that), so I'd suggest explicitly using another port number (needs to be set both on the send and recv object). For me, if I use 7480 for example it works fine, and we can update this default in a future version. FWIW, if there's a firewall setup or http proxy you might have other issues.
The reasons others saw udpsend/udpreceive working with port 7474 is that the UDP port space is different than the TCP port space.