Port mapping back to self - hmm?
Author
My network code seemed fine, it's all TCP and works fine on localhost plus over LAN. However, lots of packet loss to my tester over the net, which I'm at least starting to deal with. Rather than keep asking the tester to repeatadly test small changes I would like to forward the port (at testers end via router) back to myself (or elsewhere on my LAN). Is this possible to do on the same port? It seems the only way is to remap the port to another, else there's a paradox (I guess instance 2 is getting echos when replying? - though it does connect)...or is there?
How about just asking for remote login access to the tester's machine? In the unix/linux world that would be via ssh, in the windows world either remote desktop or terminal services.
Author
That's a great idea which I didn't consider, probably as I don't want to waste resources with something which can be prevented in code. I do have the option to run an old PIII at testers end over VNC. However it's not a perfect solution due to limited bandwidth (VNC is slow enough over LAN - perhaps it's just the P3 lol). Of course I could just automate/remote the client, but it doesn't compare to having 2 instances side-by-side, both instantly the latest build!
edit: btw, the tester's router has a bug (latest firmware) where the mapped port can not change (10000 in, to 10000 out replies ... 10000 in, to 10001 out gets lost)
[Edited by - jezham on July 20, 2010 9:48:03 AM]
edit: btw, the tester's router has a bug (latest firmware) where the mapped port can not change (10000 in, to 10000 out replies ... 10000 in, to 10001 out gets lost)
[Edited by - jezham on July 20, 2010 9:48:03 AM]
Author
I've solved this...the packets were simply too big. Even though I would use send/recieve return values inside a while loop, it was just unrealiable with big packets. What size packets do people use? I've experimented between 1K and 256K...seems over WiFi, 1K is about correct?
UDP does not support packets larger than 65k. IP will generally fragment packets less than 1.5 kB or so (depending on MTU). Some broken IP networks don't deal with fragmented IP at all.
For TCP, "packet" size doesn't matter.
For TCP, "packet" size doesn't matter.
Quote:Original post by jezham
I've solved this...the packets were simply too big. Even though I would use send/recieve return values inside a while loop, it was just unrealiable with big packets. What size packets do people use? I've experimented between 1K and 256K...seems over WiFi, 1K is about correct?
When doing network programming, always check return codes for each and every call. Unless there is a success (as per platform documentation), read the documentation on what specific error means. There's only about 50,000 things that can go wrong when doing recv() or send().
It would be (WSA)EMSGSIZE in this case (for >64k).
When exceeding MTU, there is no reliable indication. Starting with packet size of 536 (IIRC) is a good start.
Author
Yes, by packet size I mean size of buffer to be sent of course (I was shocked to find the apparent randomness of the return value). This was fine when only throwing a few bits around, but for large data it was like dialup, and increasing the size was causing wifi issues quick (my tester has a perfect unreliable setup over a repeater!).
I'm now giving the enet library a go (as mentioned in FAQ). Their short tutorial is plenty of documentation for me, especially now that I've more experience with haggling winsock2 and losing!
Thanks for posts +
edit: btw, I had to use 2 ports to do the port-mapped-rebound-test!
[Edited by - jezham on July 21, 2010 7:33:27 PM]
I'm now giving the enet library a go (as mentioned in FAQ). Their short tutorial is plenty of documentation for me, especially now that I've more experience with haggling winsock2 and losing!
Thanks for posts +
edit: btw, I had to use 2 ports to do the port-mapped-rebound-test!
[Edited by - jezham on July 21, 2010 7:33:27 PM]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
