You need to know who is initiating the connection and who is receiving. Port forwarding is directional.
Lets say your embedded application is the receiver, it's local address on your network is 192.168.1.100, and it's listening on port 8888.
Your router's outside address is 22.214.171.124
Your neighbor is going to connect from a PC on his network to your server.
His PC on his network is 192.168.1.3
His routers's outside address is 126.96.36.199
By default, nearly all home routers allow all outbound traffic, but block all inbound traffic unless the "conversation" was initiated from inside the local network.
It will help to grab a pencil and paper and draw out the following as you read it:
When your neighbor's PC tries to hit your server there are two immediate problems. First of all, if he tries to send a packet to 192.168.1.100 his computer is going to try and find that device on his network, not yours. He will have to address any communication to your Public, outside address of 188.8.131.52. The second problem is that once that packet gets to your router the router sees it an uninvited traffic and simply ignores it. Even if it accepted it, it wouldn't know where to send it because every device behind your router shares that one address. This is where the port forward comes in. You need to define the port forward on your public address (184.108.40.206) router to map UDP port 8888 from any source (or at least your neighbor's public IP address) to UDP port 8888 on your server at 192.168.1.100. This does two things, it tells the router to be looking for uninvited traffic on it's UDP port 8888 and then where to send that traffic, altering the IP addresses and port numbers as it goes. Note that TCP and UDP ports aren't the same, so make sure the forward matches the protocol you are using.
So the traffic leaves his PC going from source address 192.168.1.3 to destination address 220.127.116.11 port 8888. His router creates an entry for the conversation, effectively a temporary port forward that sends any reply to the request to 192.168.1.3 and also changes the source address to it's own outside address, 18.104.22.168 and some random port, say 6789. So now the packet is from 22.214.171.124 port 6789 to 126.96.36.199 port 8888. Your router receives the packet and notes that it has a port map for the destination port. It alters the destination address to your mapped address, 192.168.1.100, and port, 8888, and send the packet to the inside address. Your server receives the packet and sees it as with a source address of 188.8.131.52 port 6789 and destination of 192.168.1.100 port UDP 8888. When your server replies it should use the source address as it's destination. If it doesn't it won't get far. If it does, the entire process gets "unwrapped", your router exchanges your private inside 192.168.1.100 address for it's public outside address and sends it to your neighbor's router. His router (hopefully) recognizes your traffic as a response to the initial request. It removes it's outside address and port and replaces it with your neighbor's inside address and original port. The packet arrived back at your neighbor's PC with a source of 184.108.40.206 and UDP port 8888, and a destination address of 192.168.1.3 and whatever port was used to initiate the dialog.
The port forward is only needed on the end receiving the connection, not the one originating it.
Both ends "think" the other end is a public IP address, not the local 192.168.1.x address. This is important for firewall rules, particularly on the end PC's.
On the originating end the NAT router makes (almost) everything transparent.
If you reply to any port other than the one that originated the connection the source router can't match the request and reply, so your reply will not be recognized and will be ignored. Some protocols, like FTP, SIP, and others open additional connections. Most of these require "helper" code in the routers to be able to match up requests and replies. Since your little embedded app is unlikely to be popular enough to cause the router manufacturers to include a "helper" (aka Application Layer Gateway, ALG) it's best to just not do that.