Re: [UDT] UDT (Appears) to not complete the full NAT cycle
Brought to you by:
lilyco
Menu
▾
▴
Re: [UDT] UDT (Appears) to not complete the full NAT cycle
|
From: Sanjay U. <san...@ya...> - 2006-06-08 10:39:42
|
Hi Yunhong,
I am contemplating both the ideas, however changing UDT headerst would let the applications allow concurent listens on the server side. I am looking at the details and would mail you for more help.
If we can have a chat (in afew days time) at a preferrable time, it would be good.
Cheers
Sanjay Upadhyay
Yunhong Gu <yu...@la...> wrote:
The simplest way to modify UDT to support your requirement is to change
the connect() method in core.cpp. In rendzevous mode, although both side
need to provide the peer side's IP, you can change it (by removing the IP
address check) so that only one of them (the one behind NAT) need to
provide IP, the other does not.
This does not reproduce the original listen/accept mode, of course, since
you can only set up one connection.
The complicated way is to write a new class that uses one single UDP
socket to send and receive data to multiple UDT sockets. You will need to
add one more filed into the UDT header so that packet belong to different
UDT socket can be recognized. This requires a lot of change, so I don't
recommend.
Yunhong
On Mon, 5 Jun 2006, Sanjay Upadhyay wrote:
> Hi Yunhong,
> I will be pleased to work on it. I am giving the src code a go through so that it can help me understand a bit.
> expecting your reply soon..
>
> regards
> Sanjay Upadhyay
>
> Yunhong Gu wrote:
> Sanjay,
>
> I understand your requirements, but the current UDT version does not
> support it, unless you are willing to make some necessary changes by
> yourself. If you want to do so, I can tell you more details.
>
> Yunhong
>
>
>
> On Sun, 4 Jun 2006, Sanjay Upadhyay wrote:
>
>> Hi Yunhong,
>>
>> Thanks for the suggestion. The suggested idea couldnt be made to work, since the server side has to connect to the client and client has to connect to the client. so this means server has to know before hand which client to connect. logically it does'nt fit into my application. Next, I tried this :-
>>
>> bool rz = true;
>> int err = UDT::setsockopt( socket, 0, UDT_RENDEZVOUS, &rz, sizeof(bool));
>> if (err == UDT::ERROR) {
>> printf("setsockopt(UDT_RENDEZVOUS) = %s\n", UDT::getlasterror().getErrorMessage());
>> }
>> int err = UDT::bind(socket, (SOCKADDR *) &addr, sizeof(addr));
>> if (err == UDT::ERROR) {
>> printf("Bind Error: = %s\n", UDT::getlasterror().getErrorMessage());
>> return 1;
>> }
>> UDT::listen( socket, 1); // Making the socket Listen
>> UDTSOCKET newSocket = UDT::accept( socket, (sockaddr *) &newAddr, &nNewAddr);
>>
>> this above code (I just tried) didnt work, it gave me "Send" "Debug" Error. And I suppose the way to use Rendezvous connection is to initiate connect from both ends as I said above, which really doesnt serve my application purpose.
>>
>> If I understand correctly, UDT has a new port for reply, on the server side, so that it can keep accepting on the original port (listening on).
>>
>> But as I see, this has some issues, when the clients are behind NAT's. I dont know if someone in the list has tried to work from behind NAT to have a connection. I am assuming from different cisco router docs, that they too have a similar policy as iptables for natting UDP packets.
>>
>> Can you please answer me
>> 1) Can the UDT be used as a Server Client, where the server preserves the src port it listens on, for replies ?
>> 2) And do we have a list of NAT's where the present UDT implementation works soundly. (I Know vmware nat it works)
>>
>> warm regards
>>
>>
>>
>> Yunhong Gu wrote:
>>
>> Hi, Sanjay,
>>
>> The UDT server creates a new UDP socket upon receiving a new connection
>> request. The new socket has a different port number.
>>
>> You may use the RENDEZVOUS mode connection. It overkills, but should
>> work.
>>
>> Yunhong
>>
>> Yunhong Gu, Ph.D., Research Scientist
>>
>> National Center for Data Mining
>> University of Illinois at Chicago
>> SEO 700, M/C 249, 851 S Morgan St
>> Chicago, IL 60607-7045
>> T (312) 413-9576
>> F (312) 355-0373
>>
>> On Fri, 2 Jun 2006, Sanjay Upadhyay wrote:
>>
>>> Hi Yunhong,
>>>
>>> Here is an issue which severely restricts UDT. (apparently)
>>> I have an existing send / recv file, which seems to not work in an environment where the requester is behind an IPTABLES nat and the responder is on the lan without any firewall.
>>>
>>> REQUEST DIRECTION
>>> CLIENT-A -----> IPTABLES-NAT ---> SERVER
>>> RESPONSE DIRECTION (BROKEN)
>>> SERVER ------> IPTABLES-NAT -X-> CLIENT-A
>>>
>>> here the iptables-nat is not sending the response back to the client-A where the request should go, hence the communication is not established, and a UDT::Connect() returns an error.
>>>
>>> Apparently it looks like an iptables-nat configuration issue. So I wrote down a simple UDP based communication from client-A to server and which works OK. SO, I turned to the ehthereal captures.. and here is what I got..
>>>
>>> Here is the setup
>>> Server listens on port 9800 with IP 192.168.0.78.
>>> client-A is behind a iptables-nat and has the 172.16.54.11 address.
>>> Nats public interface is 192.168.0.100 and internal interface is 172.16.54.1
>>>
>>> 1. CLIENT-A : --> 172.16.54.11:1456 --> 192.168.0.78:9800
>>> 2. NAT : <-- 172.16.54.11:1456 --> 172.16.54.1:9788
>>> 3. NAT: --> 192.168.0.100:9788 --> 192.168.0.78:9800
>>> 4. SERVER: --> 192.168.0.78:13221 --> 192.168.0.100:9788
>>> 5. NAT: <-- Rejects, as the src port of the UDP response is 13221, while its looking for an UDP response with src port as 9800, for PORT Preservation and reforwarding back to 172.16.54.11:1456 (it's originating IP:PORT)
>>>
>>> Is there a way that the responses preserve the source port the (acting) server is listening on ?
>>>
>>> regards
>>>
>>>
>>> Sanjay Upadhyay
>>> Mobile +91-9231683108
>>> AIM/Yahoo/Hotmail (Screen Name) - saneax
>>> ICQ 76529342
>>> SKYPE glowfriend
>>> __________________________________________________
>>> Do You Yahoo!?
>>> Tired of spam? Yahoo! Mail has the best spam protection around
>>> http://mail.yahoo.com
>>
>>
>>
>> Sanjay Upadhyay
>> Mobile +91-9231683108
>> AIM/Yahoo/Hotmail (Screen Name) - saneax
>> ICQ 76529342
>> SKYPE glowfriend
>> __________________________________________________
>> Do You Yahoo!?
>> Tired of spam? Yahoo! Mail has the best spam protection around
>> http://mail.yahoo.com
>
>
>
> Sanjay Upadhyay
> Mobile +91-9231683108
> AIM/Yahoo/Hotmail (Screen Name) - saneax
> ICQ 76529342
> SKYPE glowfriend
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
_______________________________________________
UDT-general mailing list
UDT...@li...
https://lists.sourceforge.net/lists/listinfo/udt-general
Sanjay Upadhyay
Mobile +91-9231683108
AIM/Yahoo/Hotmail (Screen Name) - saneax
ICQ 76529342
SKYPE glowfriend
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com |
