Re: Legacy OpenTransport problem
Re: Legacy OpenTransport problem
- Subject: Re: Legacy OpenTransport problem
- From: Zachary and Meagan <email@hidden>
- Date: Tue, 18 Jul 2006 11:56:20 -0700
// -- specify a recipt buffer
data.addr.maxlen = sizeof(InetAddress);
data.addr.len = sizeof(InetAddress);
data.addr.buf = (UInt8*)&from;
data.opt.maxlen = 0;
data.opt.len = 0;
data.opt.buf = 0;
data.udata.maxlen = maxPacketDataSize;
data.udata.len = 0;
data.udata.buf = (UInt8*)packet->data;
// -- receive a packet
result = OTRcvUData( endpoint, &data, &flags );
if (result == kOTNoError)
{
// -- get the address that the packet came from
packet->address.host = from.fHost; ***** HERE IS THE ADDRESS I
USE *****
packet->address.port = from.fPort;
...
On Jul 18, 2006, at 11:48 AM, Duane Murphy wrote:
I'm making some guesses here because your terminology doesn't seem
complete.
This sounds like the server is looking at an IP address embedded
within
the data delivered to the server.
When a packet traverses through routers and NAT routers, the local IP
address of the source will not be seen at the destination, the routers
will fix up the packet such that it has the correct addresses for a
traversal back.
How is the server determining the IP address of the client in order to
send a response?
It seems that you say so here:
The client's IP (again retrieved from the client's message) seems
to be a
local space IP when the server gets it.
Don't embed IP addresses in the data payload of packets. It's useless
and won't work. The source address is retrievable from the stack. It
depends on what networking APIs you're using (and I'd have to look
it up
anyhow), but you should be able to get the source address of the UDP
packet at the server. Use that address to reply.
...Duane
--- At Tue, 18 Jul 2006 11:39:06 -0700, Zachary and Meagan wrote:
Sorry for follow up, but there is a mistake below. Basically when the
server receives the client's message (which works fine because the
server is on a static IP), the server looks at where the message came
from and uses that IP to send a receipt back to the client. The
client's IP (again retrieved from the client's message) seems to be a
local space IP when the server gets it. Anyway, just wanted to be
clear.
On Jul 18, 2006, at 11:24 AM, Zachary and Meagan wrote:
Basically I have some cross platform code (windows <-> mac) that is
probably considered out-dated at this point. I had tested it with
success on a local network, so I thought (incorrectly) that it
would work fine for most situations.
In a nut shell I am using UPD (connectionless) for both WinSock and
OT. The issue I am running into is that the server app is running
using a static IP. The clients I am testing with are behind two
layers of routers. When the server gets the client's request to
join, the server simply uses the IP address as is to sent a receipt
to the sender. The problem is that the IP address seems to the
address of the first router (which is a local address). So of
course the client's message never makes it to the server.
I am assuming if I had used a connection based approach this
problem would be taken care of behind the scene? Unfortunately I
have quite a bit of code surrounding my current approach. What are
my options?
...Duane
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden