udt-general — UDT General Discussion

[UDT] General questions about performance

[Yang <3jl...@sn...>]

hi all, i tested sendfile/recvfile between two hosts on the same
university network (~1ms lag), but found the performance to be poor.
using http, i was able to transfer a 6.6MB file in 7.7s (~860KB/s),
but this took 17s using udt. one host is linux (just used 'make' to
build), the other is windows xp (built using visual studio).

i was wondering:

- is this result expected? i realize that my hosts have low latencies,
but i didn't think this explains the magnitude of the hit...nor that
the performance of udt would/should in any situation be worse than
tcp. my understanding is that a primary aim of udt is to maximize
throughput.

- is there anything (reasonably effortless) i can do to see better performance?

- are there other file transfer apps that do offer improved bandwidth
usage over tcp? i glanced at some of the papers' related works, and
the only other released software i found was tsunami (which i have not
tried).

- is there any reason why i should not expect to find such an app? (i
have zero background in networking. things i can imagine are:
userspace implementations have too much overhead to compete with
kernel tcp stack; isp's/routers prioritize tcp packets, which play
fairly, over other packets; etc.)

to give some background/a better idea of what i seek: i was ftp-ing
large files today between two hosts across the US at disappointing
rates when i got the idea to look into alternatives to tcp. i realize
that people have long researched protocols and congestion controls to
maximize throughput, particularly targeting the case of high
bandwidth*latency. i didn't want to subject myself to too much pain in
this endeavor (e.g., rebuilding kernels would be going too far), so i
set about looking on various open-source software sites for real-world
implementations using udp - and that's how i found udt. i haven't
found any other apps, though (except for tsunami, but i imagine that
udt is an improvement thereon).

thanks very much in advance!

[UDT] overlapped IO for unreliable delivery

[Ran L. <ra...@ho...>]

Hi,

Did anyone implement overlapped IO for sendmsg() and recvmsg() ?
Anyone knows if there are such plans?

thanks, Ano.

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

[UDT] Errors in app/cc.h

[Harald s. <sc...@rr...>]

Hi,
there are some errors in the implementation of BIC and Scalable
in app/cc.h.

 o when receiving an DUPACK, m_issthresh is not reduced.
   (m_dCWndSize is set to m_issthresh after the first non duplicate
    ACK arrives. So m_dCWndSize is not reduced at all.)
 o It is necessary to  distinguish between SlowStart and BICSlowStart.
 o If BIC is in BICSlowStart and an DUPACK arrives, BICSlowStart
   must be aborted.

I changed some Parameters Medienberichten in TCP-BIC to achieve an
similar behaviour than Linux-BIC. (BIC is the default Congestion Control
algorithm since Kernel 2.6.13). This can of course easily be revoked....



diff app/cc.h app/cc.h_org
42d41
<       m_bBICSlowStart = false;
113,114c112
<    bool m_bBICSlowStart;
<
---
>
137d134
<           {
139,141d135
<             if (m_dCWndSize >= m_issthresh)
<               m_bSlowStart = false;
<            }
143d136
<           {
145d137
<           }
154d145
<       m_bSlowStart = false;
156,164c147,150
<         {
<          m_issthresh *= 0.5;
<          m_dCWndSize = m_issthresh;
<         }
<       else
<         {
<          m_issthresh=getPerfInfo()->pktFlightSize*0.875;
<          m_dCWndSize=m_issthresh;
<         }
---
>          m_dCWndSize *= 0.5;
>       else
>          m_dCWndSize *= 0.875;
>
243c229
<       if (!m_bBICSlowStart)
---
>       if (!m_bSlowStart)
245,246c231,232
<          if ((m_dTargetWin - m_dCWndSize) < m_iSMax)
<              m_dCWndSize += (m_iSMax/36)/m_dCWndSize;
---
>          if (m_dTargetWin - m_dCWndSize < m_iSMax)
>             m_dCWndSize += (m_dTargetWin - m_dCWndSize)/m_dCWndSize;
248a235
>
256c243
<             m_bBICSlowStart = true;
---
>             m_bSlowStart = true;
271c258
<             m_bBICSlowStart = false;
---
>             m_bSlowStart = false;
283,284c270
<          m_issthresh=(getPerfInfo()->pktFlightSize)*0.7;
<          m_dCWndSize = m_issthresh;
---
>          m_dCWndSize *= 0.875;
287a274
>          {
290c277
<
---
>          }
292d278
<       m_bBICSlowStart = false;
296,299c282,285
<    static const int m_iLowWindow = 16;
<    static const float m_iSMax = 16;
<    static const float m_iSMin = 0.1;
<    static const int m_iDefaultMaxWin = 100000;
---
>    static const int m_iLowWindow = 38;
>    static const int m_iSMax = 32;
>    static const int m_iSMin = 1;
>    static const int m_iDefaultMaxWin = 1 << 29;



Bye,
Harald

Re: [UDT] SO_REUSEADDR

[Yunhong Gu <yu...@la...>]

Yes, you can use that line of code to determine if the response is from 
the expected source.

However, I am not sure if by repeating the process UDT can get the correct 
response. I read somewhere that SO_REUSEADDR on UDP has undetermined 
behavior on different systems.

You can test it though. Simply include the "secure" checking code into the 
while loop right above it.

Yunhong


On Sat, 22 Jul 2006 ar...@ph... wrote:

> Yunhong,
>
>  Thank you for your reply.  I do have an idea.  Can you tell me if this is possible.
>
>  Can UDT use IP:port obtained from getpeername() to confirm that the socket is the right one prior to set m_bConnected=ture.  If the socket is wrong, can UDT go thru this again with other sockets until it finds the right one.
>
>  P.S.  In void CUDT::connect(const sockaddr* serv_addr)
>  ...
>     if ((0 != strcmp(req_ip, res_ip)) || (0 != strcmp(req_port, res_port)))
>  ...
>
>  Art Pharn
>
> udt...@li... wrote:
>  Send UDT-general mailing list submissions to
> udt...@li...
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.sourceforge.net/lists/listinfo/udt-general
> or, via email, send a message with subject or body 'help' to
> udt...@li...
>
> You can reach the person managing the list at
> udt...@li...
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of UDT-general digest..."
>
>
> Today's Topics:
>
> 1. SO_REUSEADDR (ar...@ph...)
> 2. Re: SO_REUSEADDR (Yunhong Gu)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 21 Jul 2006 13:31:12 -0700 (PDT)
> From:
> Subject: [UDT] SO_REUSEADDR
> To: udt...@li...
> Cc: Art Pharn
> Message-ID: <200...@we...>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Yunhong,
>
> First, I'd like to complement on the UDT.
>
> I have a question about the SO_REUSEADDR. Does the implementation of UDT prohibit the use of SO_REUSEADDR? When I modify UDT such that I can set the SO_REUSEADDR option directly on sockets that use the same local port, to the same remote host but with diff. remote ports, I found out that I could get a connect on the wrong socket, i.e wrong remote port.
>
> Thanks,
>
> Art Pharn
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: http://sourceforge.net/mailarchive/forum.php?forum=udt-general/attachments/20060721/96b597ac/attachment.html
>
> ------------------------------
>
> Message: 2
> Date: Fri, 21 Jul 2006 16:06:29 -0500 (CDT)
> From: Yunhong Gu
> Subject: Re: [UDT] SO_REUSEADDR
> To: Art Pharn
> Cc: udt...@li...
> Message-ID:
>
> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
>
>
>
> I think it is the problem of UDP with SO_REUSEADDR. When you have two UDP
> sockets bound to the same port, it seems there is no way to guarantee
> that an incoming packet goes to one socket rather than the other, becuase
> UDP is connectionless, it cannot use source IP:port to determine the
> destination socket. The outcome may depend on different system
> implementations.
>
> Due to the same reason, the conenction request from remote host may reach
> any local UDT listening socket, thus you may get wrong connection.
>
> I don't think there is any way to support SO_REUSEADDR in UDT, but if you
> have any idea, I would like to try.
>
> Thanks
> Yunhong
>
>
> On Fri, 21 Jul 2006 ar...@ph... wrote:
>
>> Yunhong,
>>
>> First, I'd like to complement on the UDT.
>>
>> I have a question about the SO_REUSEADDR. Does the implementation of UDT prohibit the use of SO_REUSEADDR? When I modify UDT such that I can set the SO_REUSEADDR option directly on sockets that use the same local port, to the same remote host but with diff. remote ports, I found out that I could get a connect on the wrong socket, i.e wrong remote port.
>>
>> Thanks,
>>
>> Art Pharn
>>
>
>
>
> ------------------------------
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>
> ------------------------------
>
> _______________________________________________
> UDT-general mailing list
> UDT...@li...
> https://lists.sourceforge.net/lists/listinfo/udt-general
>
>
> End of UDT-general Digest, Vol 2, Issue 4
> *****************************************
>
>

Re: [UDT] SO_REUSEADDR

[<ar...@ph...>]

Yunhong,
   
  Thank you for your reply.  I do have an idea.  Can you tell me if this is possible.
   
  Can UDT use IP:port obtained from getpeername() to confirm that the socket is the right one prior to set m_bConnected=ture.  If the socket is wrong, can UDT go thru this again with other sockets until it finds the right one.   
   
  P.S.  In void CUDT::connect(const sockaddr* serv_addr)
  ...
     if ((0 != strcmp(req_ip, res_ip)) || (0 != strcmp(req_port, res_port)))
  ...
   
  Art Pharn
  
udt...@li... wrote:
  Send UDT-general mailing list submissions to
udt...@li...

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/udt-general
or, via email, send a message with subject or body 'help' to
udt...@li...

You can reach the person managing the list at
udt...@li...

When replying, please edit your Subject line so it is more specific
than "Re: Contents of UDT-general digest..."


Today's Topics:

1. SO_REUSEADDR (ar...@ph...)
2. Re: SO_REUSEADDR (Yunhong Gu)


----------------------------------------------------------------------

Message: 1
Date: Fri, 21 Jul 2006 13:31:12 -0700 (PDT)
From: 
Subject: [UDT] SO_REUSEADDR
To: udt...@li...
Cc: Art Pharn 
Message-ID: <200...@we...>
Content-Type: text/plain; charset="iso-8859-1"

Yunhong,

First, I'd like to complement on the UDT. 

I have a question about the SO_REUSEADDR. Does the implementation of UDT prohibit the use of SO_REUSEADDR? When I modify UDT such that I can set the SO_REUSEADDR option directly on sockets that use the same local port, to the same remote host but with diff. remote ports, I found out that I could get a connect on the wrong socket, i.e wrong remote port.

Thanks,

Art Pharn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://sourceforge.net/mailarchive/forum.php?forum=udt-general/attachments/20060721/96b597ac/attachment.html 

------------------------------

Message: 2
Date: Fri, 21 Jul 2006 16:06:29 -0500 (CDT)
From: Yunhong Gu 
Subject: Re: [UDT] SO_REUSEADDR
To: Art Pharn 
Cc: udt...@li...
Message-ID: 

Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed



I think it is the problem of UDP with SO_REUSEADDR. When you have two UDP
sockets bound to the same port, it seems there is no way to guarantee 
that an incoming packet goes to one socket rather than the other, becuase 
UDP is connectionless, it cannot use source IP:port to determine the 
destination socket. The outcome may depend on different system 
implementations.

Due to the same reason, the conenction request from remote host may reach 
any local UDT listening socket, thus you may get wrong connection.

I don't think there is any way to support SO_REUSEADDR in UDT, but if you 
have any idea, I would like to try.

Thanks
Yunhong


On Fri, 21 Jul 2006 ar...@ph... wrote:

> Yunhong,
>
> First, I'd like to complement on the UDT.
>
> I have a question about the SO_REUSEADDR. Does the implementation of UDT prohibit the use of SO_REUSEADDR? When I modify UDT such that I can set the SO_REUSEADDR option directly on sockets that use the same local port, to the same remote host but with diff. remote ports, I found out that I could get a connect on the wrong socket, i.e wrong remote port.
>
> Thanks,
>
> Art Pharn
>



------------------------------

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

------------------------------

_______________________________________________
UDT-general mailing list
UDT...@li...
https://lists.sourceforge.net/lists/listinfo/udt-general


End of UDT-general Digest, Vol 2, Issue 4
*****************************************

Re: [UDT] SO_REUSEADDR

[Yunhong Gu <yu...@la...>]

I think it is the problem of UDP with SO_REUSEADDR. When you have two UDP
sockets bound to the same port, it seems there is no way to guarantee 
that an incoming packet goes to one socket rather than the other, becuase 
UDP is connectionless, it cannot use source IP:port to determine the 
destination socket. The outcome may depend on different system 
implementations.

Due to the same reason, the conenction request from remote host may reach 
any local UDT listening socket, thus you may get wrong connection.

I don't think there is any way to support SO_REUSEADDR in UDT, but if you 
have any idea, I would like to try.

Thanks
Yunhong


On Fri, 21 Jul 2006 ar...@ph... wrote:

> Yunhong,
>
>  First, I'd like to complement on the UDT.
>
>  I have a question about the SO_REUSEADDR.  Does the implementation of UDT prohibit the use of SO_REUSEADDR?   When I modify UDT such that I can set the SO_REUSEADDR option directly on sockets that use the same local port, to the same remote host but with diff. remote ports, I found out that I could get a connect on the wrong socket, i.e wrong remote port.
>
>  Thanks,
>
>  Art Pharn
>

[UDT] SO_REUSEADDR

[<ar...@ph...>]

Yunhong,
   
  First, I'd like to complement on the UDT.  
   
  I have a question about the SO_REUSEADDR.  Does the implementation of UDT prohibit the use of SO_REUSEADDR?   When I modify UDT such that I can set the SO_REUSEADDR option directly on sockets that use the same local port, to the same remote host but with diff. remote ports, I found out that I could get a connect on the wrong socket, i.e wrong remote port.
   
  Thanks,
   
  Art Pharn

Re: [UDT] common.cpp: Compiler/Assembler error on IA64, "invalid character", "suffix or operands invalid"

[Franz P. <f....@fz...>]

Hi,

sorry, my mistake.

-e arch=AMD64 does the trick 8-)

Thanks,

Franz.

Yunhong Gu wrote:
> 
> The instruction "nop" is used for Itanium. Did you try to compile without 
> -DIA64 (or -e arch=IA64)?
> 
> Thanks
> Yunhong
> 
> On Thu, 6 Jul 2006 f....@fz... wrote:
> 
>> Hi,
>>
>> when building udt3.0 on an IA64 (Dual Intel Xeon)-smp-system, I get the attached error. I also attached the .s output.
>>
>> I use Suse 9.3 with all the latest patches.
>>
>> Can you give me any hints on where to look for the fault?
>>
>> Thanks,
>>
>> Franz.
>>
> 
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> UDT-general mailing list
> UDT...@li...
> https://lists.sourceforge.net/lists/listinfo/udt-general

Re: [UDT] common.cpp: Compiler/Assembler error on IA64, "invalid character", "suffix or operands invalid"

[Yunhong Gu <yu...@la...>]

The instruction "nop" is used for Itanium. Did you try to compile without 
-DIA64 (or -e arch=IA64)?

Thanks
Yunhong

On Thu, 6 Jul 2006 f....@fz... wrote:

> Hi,
>
> when building udt3.0 on an IA64 (Dual Intel Xeon)-smp-system, I get the attached error. I also attached the .s output.
>
> I use Suse 9.3 with all the latest patches.
>
> Can you give me any hints on where to look for the fault?
>
> Thanks,
>
> Franz.
>

[UDT] common.cpp: Compiler/Assembler error on IA64, "invalid character", "suffix or operands invalid"

[<f....@fz...>]

Hi,

when building udt3.0 on an IA64 (Dual Intel Xeon)-smp-system, I get the attached error. I also attached the .s output.

I use Suse 9.3 with all the latest patches.

Can you give me any hints on where to look for the fault?

Thanks,

Franz.

Re: [UDT] network <-> host order conversion of port number missing

[Yunhong Gu <yu...@la...>]

Hi, thanks for the information. I have updated CVS to reflect this fix.

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 Tue, 27 Jun 2006 f....@fz... wrote:

> Hi,
>
> I am not getting the latest UDT version from the CVS to run between AIX/POWERPC <-> LINUX/INTEL and LINUX/INTEL <-> LINUX/INTEL.
>
> Apparently there is the byte order conversion of sin_port of struct sockaddr_in missing, check out the attached workaround.
>
> Kind regards,
>
> Franz Petri
>

[UDT] network <-> host order conversion of port number missing

[<f....@fz...>]

Hi,

I am not getting the latest UDT version from the CVS to run between AIX/POWERPC <-> LINUX/INTEL and LINUX/INTEL <-> LINUX/INTEL.

Apparently there is the byte order conversion of sin_port of struct sockaddr_in missing, check out the attached workaround.

Kind regards,

Franz Petri

[UDT] ping time

[<si...@ms...>]

<div><pre>

=20
     I try to execute ping program that come form the package.
     Whatever the same machine or the different machines that in the same r=
outer, the RTT is not equal zero.
     Is it a normal situation?</pre></div><br><span style=3D"font-size:13px=
">--- =E6=9C=AC=E9=83=B5=E4=BB=B6=E4=BE=86=E8=87=AAHiNet WebMail ---</span>

Re: [UDT] UDT to AIX portability, byte order, endianess problem

[Yunhong Gu <yu...@la...>]

Yes, you are right. somehow I skiped the testing between machines with 
different endianess. I have updated the CVS to reflect this bug fix.

Thanks,
Yunhong

On Tue, 13 Jun 2006 f....@fz... wrote:

> Hi
>
> I am trying to port UDT to AIX.
>
> Aside from some compiling difficulties (most of them arising due to gcc bugs - I had to use gcc version 3.2.1 - and the pthreads - see the additional flags in my Makefile below), I could not get the app/appserver/appclient application to work across AIX/POWERPC-boarders, meaning I could run the programs on localhost, even on 2 different AIX machines, and connect, but when trying to connect between AIX/POWERPC and LINUX/INTEL machines I got no connection with timeout errorsn no matter on which side the client/server was sitting.
>
> I suspected this to be an issue of byte ordering, and I found it to be in file src/channel.cpp, for example in line 155:
>
> const CChannel& CChannel::operator<<(CPacket& packet) const
> {
>   if (m_bEndianess)
>   {
>      // convert control information into network order
>      if (packet.getFlag())
>         for (int i = 0, n = packet.getLength() / 4; i < n; ++ i)
>            *((uint32_t *)packet.m_pcData + i) = htonl(*((uint32_t *)packet.m_pcData + i));
>
>      // convert packet header into network order
>      packet.m_nHeader[0] = htonl(packet.m_nHeader[0]);
>      packet.m_nHeader[1] = htonl(packet.m_nHeader[1]);
>   }
>
>
>
>
> so on a Big Endian architecture (m_bEndianess = true) this does a htonl(), converting the byte order from host to network order, but on a Little Endian architecture it doesnt.
>
>> From my understanding Network Byte Order IS ALREADY Big Endian, so shouldn't the littleendian machine actually do this conversion (an the bigendian skip it)?
>
> There are a few more htonl()s like the one above.
>
> I got everything to work with the changes in the source I pasted in below.
>
> Any further hints and suggestions for porting UDT to AIX are welcome :-)
>
> Kind regards,
>
> Franz Petri.
>
> PS: Just for curiousity: Did anybody get this to acutally work on OSX/POWERPC?! Or are the "Mac"-Powerpcs not bigendian?
>
>
>
>
>
>

[UDT] UDT to AIX portability, byte order, endianess problem

[<f....@fz...>]

Hi

I am trying to port UDT to AIX.

Aside from some compiling difficulties (most of them arising due to gcc bugs - I had to use gcc version 3.2.1 - and the pthreads - see the additional flags in my Makefile below), I could not get the app/appserver/appclient application to work across AIX/POWERPC-boarders, meaning I could run the programs on localhost, even on 2 different AIX machines, and connect, but when trying to connect between AIX/POWERPC and LINUX/INTEL machines I got no connection with timeout errorsn no matter on which side the client/server was sitting. 

I suspected this to be an issue of byte ordering, and I found it to be in file src/channel.cpp, for example in line 155:

const CChannel& CChannel::operator<<(CPacket& packet) const
{
   if (m_bEndianess)
   {
      // convert control information into network order
      if (packet.getFlag())
         for (int i = 0, n = packet.getLength() / 4; i < n; ++ i)
            *((uint32_t *)packet.m_pcData + i) = htonl(*((uint32_t *)packet.m_pcData + i));

      // convert packet header into network order
      packet.m_nHeader[0] = htonl(packet.m_nHeader[0]);
      packet.m_nHeader[1] = htonl(packet.m_nHeader[1]);
   }




so on a Big Endian architecture (m_bEndianess = true) this does a htonl(), converting the byte order from host to network order, but on a Little Endian architecture it doesnt.

>From my understanding Network Byte Order IS ALREADY Big Endian, so shouldn't the littleendian machine actually do this conversion (an the bigendian skip it)?

There are a few more htonl()s like the one above.

I got everything to work with the changes in the source I pasted in below.

Any further hints and suggestions for porting UDT to AIX are welcome :-)

Kind regards,

Franz Petri.

PS: Just for curiousity: Did anybody get this to acutally work on OSX/POWERPC?! Or are the "Mac"-Powerpcs not bigendian? 

Re: [UDT] UDT (Appears) to not complete the full NAT cycle

[Yunhong Gu <yu...@la...>]

Sanjay,

Following is a basic idea on the second method.

Adding one more field in the packet header. This is easy; just follow the 
examples in packet.h/packet.cpp.

You will not need the threads of sndhandler and rcvhandler. Instead, all 
UDT sockets in one process can share a single sndhandler and a single 
rcvhandler. There will be a snd queue and a rcv queue, for outbound 
packets and inbound packets, respectively.

For example, the rcvhandler check each incoming packet, and dispatch it to 
a certain UDT socket according to the socket ID in the packet header. The 
original rcvhandler can be called to further process this packet.

You also need to update the connect() method, which should not create new 
UDP socket any more.

Yunhong


On Thu, 8 Jun 2006, Sanjay Upadhyay wrote:

> 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

Re: [UDT] UDT (Appears) to not complete the full NAT cycle

[Sanjay U. <san...@ya...>]

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 

Re: [UDT] UDT (Appears) to not complete the full NAT cycle

[Yunhong Gu <yu...@la...>]

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 <yu...@la...> 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

Re: [UDT] UDT (Appears) to not complete the full NAT cycle

[Sanjay U. <san...@ya...>]

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 <yu...@la...> 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 

Re: [UDT] UDT (Appears) to not complete the full NAT cycle

[Yunhong Gu <yu...@la...>]

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 <yu...@la...> 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

Re: [UDT] UDT (Appears) to not complete the full NAT cycle

[Yunhong Gu <yu...@la...>]

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

Re: [UDT] UDT (Appears) to not complete the full NAT cycle

[Sanjay U. <san...@ya...>]

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 <yu...@la...> 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 

[UDT] UDT (Appears) to not complete the full NAT cycle

[Sanjay U. <san...@ya...>]

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 

[UDT] UDT3 final + patches for MSVC6

[Marek V. <mar...@vo...>]

Hi Yunhong.

Since the UDT3 final version still does not compile under MSVC6 out
of the box, I am (again) offering the patches...

-- Markoid

Re: [UDT] cc.h:683: error: =?windows-1252?Q?=91=5F=5Fint64=92_does_not?= =?windows-1252?Q?_name_a_type?=

[Yunhong Gu <yu...@la...>]

Hi, Franz,

Thanks for the email.

The "__int64" should be "int64_t", I forgot to change it. The GTP part=20
of code is not completed yet. If you want to use that class, you may need=
=20
to add more code by yourself (in addition to the code you already=20
changed).

Regards,
Yunhong

On Mon, 29 May 2006, Franz Petri wrote:

> Hi,
>
> I just downloaded the udt3-sources, and I am getting the following errors=
=20
> when compiling (fyi: udtperf is a self-written tool we use for udt-testin=
g=20
> and includes "cc.h"):
>
>
>
> make -C  app all
> make[1]: Entering directory `/home/xxx/programme/udt3_mod/app'
> g++ -Wall -DLINUX -I../src -O2 -finline-functions -DIA32  udtperf.cpp -c
> ../src/ccc.h:195: warning: =91class CCCVirtualFactory=92 has virtual func=
tions=20
> but non-virtual destructor
> cc.h:683: error: =91__int64=92 does not name a type
> cc.h: In member function =91virtual void CGTP::init()=92:
> cc.h:603: error: =91m_llLastRecvPkt=92 was not declared in this scope
> cc.h: In member function =91virtual void CGTP::onPktReceived()=92:
> cc.h:629: error: =91m_llLastRecvPkt=92 was not declared in this scope
>
>
>
>
> As a very quick and dirty workaround I made the following change in cc.h =
from=20
> __int64 to long long int which solves the above errors:
>
>
>
>
> *** udt3/app/cc.h       2006-03-13 17:53:25.000000000 +0100
> --- udt3_mod/app/cc.h   2006-05-29 11:07:27.000000000 +0200
> ***************
> *** 680,686 ****
>     double m_dRequestRate;
>
>     timeval m_LastGCTime;
> !    __int64 m_llLastRecvPkt;
>     int m_iLastRcvLoss;
>     int m_iRTT;
>
> --- 680,686 ----
>     double m_dRequestRate;
>
>     timeval m_LastGCTime;
> !    long long int m_llLastRecvPkt;
>     int m_iLastRcvLoss;
>     int m_iRTT;
>
>
>
>
>
> Now compilation works, but I get the following error when linking (I don'=
t=20
> know wether it is related to the above error):
>
>
>
>
>
> make -C  app all
> make[1]: Entering directory `/home/xxx/programme/udt3_mod/app'
> g++ udtperf.o -o udtperf -L../src -ludt -lstdc++ -lpthread -lm -ldl
> udtperf.o: In function `CGTP::onPktReceived()':
> udtperf.cpp:(.gnu.linkonce.t._ZN4CGTP13onPktReceivedEv[CGTP::onPktReceive=
d()]+0x17a):=20
> undefined reference to `CGTP::m_iGTPPktType'
> collect2: ld returned 1 exit status
> make[1]: *** [udtperf] Error 1
> make[1]: Leaving directory `/home/xxx/programme/udt3_mod/app'
> make: *** [app.all] Error 2
>
>
>
>
> In our udtperf.cpp the CCCFactory<CGTP> class is instantiated like this=
=20
> (which works well for all other CCCFactory objects):
>
> UDT::setsockopt(client,0,UDT_CC,new=20
> CCCFactory<CGTP>,sizeof(CCCFactory<CGTP>));}
>
>
>
>
> Another quick and dirty workaround solves the linking error:
>
> *** udt3/app/cc.h       2006-03-13 17:53:25.000000000 +0100
> --- udt3_mod/app/cc.h   2006-05-29 11:07:27.000000000 +0200
> ***************
> *** 668,674 ****
>     void requestRate(int mbps)
>     {
>        CPacket pkt;
> !       pkt.pack(0x111, const_cast<void*>((void*)&m_iGTPPktType), &mbps,=
=20
> sizeof(int));
>
>        sendCustomMsg(pkt);
>     }
> --- 668,674 ----
>     void requestRate(int mbps)
>     {
>        CPacket pkt;
> !       pkt.pack(0x111, const_cast<void*>((void*)m_iGTPPktType), &mbps,=
=20
> sizeof(int));
>
>        sendCustomMsg(pkt);
>     }
>
>
>
>
>
>
>
>
> I compile on a dual-core Pentium4, Suse 10.0, Kernel version 2.6.16.7-smp=
=20
> (vanilla), gcc version 4.0.2, glibc version 2.3.5
>
>
>
> Please apologize for any clumsy code style as I am a C++-novice. Any=20
> suggestions for a cleaner/more elegant solution are appreciated.
>
> Thank you very much,
>
> Franz Petri.
>