Re: Legacy OpenTransport problem
Re: Legacy OpenTransport problem
- Subject: Re: Legacy OpenTransport problem
- From: "Duane Murphy" <email@hidden>
- Date: Tue, 18 Jul 2006 12:28:12 -0700
It seems like you're doing the right thing here. That means the problem
is elsewhere.
I'd do some more packet sniffing to see what addresses are being used.
Maybe that pattern will show you what is happening.
You should not be seeing any local IP addresses in the wild. The address
of the client at the server should be that of the DSL Router (assuming
NAT is being used on any or all of those routers).
...Duane
--- At Tue, 18 Jul 2006 11:56:20 -0700, Zachary and Meagan wrote:
> // -- 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
>>
>
>
...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