• Advertisement
Sign in to follow this  

Port mapping back to self - hmm?

This topic is 2773 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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?

Share this post


Link to post
Share on other sites
Advertisement
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]

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement