UDP and TCP

People told me that data might go lost if I use UDP Protocol, so I have to use TCP.
But I am quite confused cause I read that the data link layer will make sure the data transfers correctly, so I suppose no data would be lost even if I use UDP cause it's based on the link layer.
Can someone solve my puzzle?

But the data link already take care of this. So no
packets should be lost.No.

Similar Messages

UDP and TCP ports

Hi:
I have a question. As we know, scanning TCP ports is a lot eaiser than UDP ports because active UDP ports don't respond and there are other reasons as well.
try{
Socket soc= new Scoket(address, portnumber);
catch(Throwable e){ System.out.println(e)}
look at the code above, it can only tell you active TCP ports for the Throwable e tells you nothing about UDP ports. An active UDP port doesn' respond to the connection call "soc". Therefore it will throw an exception(connection refused) after trying to connect an active UDP port. This exception is just like those of closed TCP ports.
What i am saying is that active UDP ports will be treated the same as closed TCP ports. They are hidden in closed TCP ports. How do i sift them out? Any solutions?

I am basically trying to determine how many UDP and TCP ports on a machine are open. Open TCP ports are easy to see. But UDP ports are tricky. Can you please tell me more in detail using a datagram socket?

BEFW11S4 UDP AND TCP PORT opening

How do i open UDP AND TCP ports specifically TCP ports: 80, 6667, 28910, 29900, 29920
UDP ports: 4321, 27900 Its for a networkable game i need to open these ports to play it.

Ok But when i try disabling the numbers in the forwarding field i run out of spaces in the field to be able to disable them Is there an advanced firewall settings that i dont know about? I put in all of the range forwarding and put the range forwarding start for example 80 originally (TCP ports: 80, 6667, 28910, 29900, 29920
UDP ports: 4321, 27900) The ones i try to disable i run out of fields to disable them in the forwarding for example there are 10 slots for disabling and Im trying to disable them on two numbers 192.168.1.101. and 192.168.1.100 So i need to disable them for both ip numbers I got 10 fields to enter it into them and 10 x 2 is more than the numbers..... You get me?? and on top of that i dont know if what i did was enough Linksys doesnt want to help me without paying 30 dollars so im just thinking i should buy a new router....... i mean they charge 39 dollars for a new router and they want me to pay 39 dollars for tech support it just doesnt make any sense........

How can I open both UDP and TCP ports

Hi,
How can i open both tcp and UDP ports for an IP in Cisco ASA?
Regards
Ejaz

Are you referring to port opening in Cisco ASA to permit certain traffic? I believe the following document should help.
http://www.cisco.com/en/US/docs/security/asa/asa82/configuration/guide/acl_overview.html
Adding a Standard Access List
hostname(config)# access-list access_list_name standard {deny | permit} {any | ip_address mask}
Example:
hostname(config)# access-list OSPF standard permit 192.168.1.0 255.255.255.0
http://www.cisco.com/en/US/docs/security/asa/asa82/configuration/guide/acl_standard.html
Adding an Extended Access List
access-list access_list_name [line line_number] [extended] {deny | permit} protocol source_address mask [operator port] dest_address mask [operator port | icmp_type] [inactive]
Example:
hostname(config)# access-list ACL_IN extended permit ip any any
http://www.cisco.com/en/US/docs/security/asa/asa82/configuration/guide/acl_extended.html
Hope this will help.

Maximum # of UDP and TCP port Mappings

Does anyone know for sure the total number of port mappings you can create on the airport extreme?
Thanks

Ok But when i try disabling the numbers in the forwarding field i run out of spaces in the field to be able to disable them Is there an advanced firewall settings that i dont know about? I put in all of the range forwarding and put the range forwarding start for example 80 originally (TCP ports: 80, 6667, 28910, 29900, 29920
UDP ports: 4321, 27900) The ones i try to disable i run out of fields to disable them in the forwarding for example there are 10 slots for disabling and Im trying to disable them on two numbers 192.168.1.101. and 192.168.1.100 So i need to disable them for both ip numbers I got 10 fields to enter it into them and 10 x 2 is more than the numbers..... You get me?? and on top of that i dont know if what i did was enough Linksys doesnt want to help me without paying 30 dollars so im just thinking i should buy a new router....... i mean they charge 39 dollars for a new router and they want me to pay 39 dollars for tech support it just doesnt make any sense........

Combining UDP and TCP connections

I am trying to build a simple client -server app, where multiple client sends price quotes to a server and the server does some analysis on these numbers and spits it back out to all the clients every 5 seconds or so. Before I start, I want to make sure I am thinking about it correctly. I was thinking that I could have on each client a UDP connection and a TCP connection, the TCP connection would be used to send the quotes to the server. This way I have a live connection and confirmed packet reception from client to server.
The UDP would be used for when the server sends back out the quotes to all the clients, since the server is just sending out back certain ones (the best quotes that is) to all the clients. Does that seem like a reasonable design?

The only reason is because the server should be sending out it's information via datagrams because it wants to send the same message to all the clients. So in my point of view it looks like it would be more efficient to send out one datagram, broadcasted instead of going through each client and sending the same thing, especially when I'm trying to send an update every 5 seconds or so.

Entering UDP and TCP numbers

^^^ Just need help with that, its for my PS3, i called Sony after getting DNS errors(80710102) and they told me i need to enter the numbers they gave me, i just want to know were to pit them... And my router is a WRT54G btw...
Message Edited by Gran_Turismo on 06-28-2007 10:39 PM

from the computer wired to the router , access the web interface of the router using http://192.168.1.1 .. the default password is "admin"...once on the ui go to the "applications and gaming" tab and click on the "port trigerring" subtab .. enter the port numbers on this page ..

How to forward UDP on TCP?

Hey everyone,
I'm behind a firewall that blocks all UDP (torrents, games...) requests.
I usually ssh to my server and forward all the trafic to it using a transparent
proxy application (sshuttle). I saw that openvpn handles UDP as well (sshuttle doesn't).
I read the documentation of openvpn but I didn't understand which flags to use
and which not to. Actually I suck at networking and I'm not even sure if the title of the question
is correct (would explain why I couldn't find anything on the forum/online).
So could you please help me out? and sorry for any mistake I did.
Thanks

OpenVPN, has two operating mode: tun and tap. Tun just tunnels IP traffic (UDP and TCP), while Tap acts like a real ethernet cable. To achieve this, OpenVPN has to make a network connection with the remote server. To do so, you have two choices again: UDP and TCP.
What you want is probably tun+tcp, which will make the UDP traffic going into OpenVPN to be transmitted over the TCP connection and go out of the server as UDP.
The config options are
proto tcp
dev tap
The wiki entry (https://wiki.archlinux.org/index.php/Op … ll_OpenVPN) should work fine for you. Just don't forget to use "proto tcp" in both server and client configs. The default setup should be perfectly fine for you.
As noted by brain0, tunelling UDP over TCP will cause higher latency on UDP. It should work fine for torrents, but the latency will be something 1.5x the latency from you and the server + the latency between the server and the final destination of the UDP traffic. Gaming on that might be painful.

UDP vs TCP (hands-on experience required)

Dearest colleagues,
I've done a few hours of research learning what I can about TCP vs UDP. I could still use some input from those of you who have used both in real-world, scaleable, distributed, commercial, and successful projects.
I have a new position at a new company. My part of this project consists of 3 types of distributed Java server programs: desktop client, data server, and controller server. Thousands of desktop clients will be periodically transferring "megs" of data to several data servers. The (singular) controller will persist metadata into a database, and also coordinate data transfer between the desktop clients and the data servers.
TCP seems appropriate for all "control" and metadata communications between all these components. Everyone talks to the controller for everything, except for the periodic transfer of the "actual" data. The desktop clients send that data directly to the appropriate data server using either UDP or TCP.
One key project requirement is the ability to provide network throttling control, so as not to saturate the client's LAN or WAN. This product mustn't disrupt the client's real-time network data (like VoiP and video conferencing). I expect the controller server to manage this.
Someone with more seniority than me at this company has suggested TFTP (which uses UDP) as the best protocol for the data transfer protocol. This person also claims that UDP allows larger packet sizes and less protocol overhead, resulting in greater data transfer rates than TCP.
I have a number of concerns and questions:
1) Can't the packet sizes be set for both UDP and TCP? If so, can't one equal both (in terms of average overhead) just by adjusting the packet sizes?
2) I realize that one needs to accomodate UDP droppage in order to compare throughput with TCP. In a LAN environment is it reasonable to assume that droppage would be minimal or zero? )Otherwise wouldn't it be a LAN problem someone would be fixing?)
3) If #2 above allows me to assume minimal UDP droppage, does the underlying packet protocol overhead difference give UDP a substantial throughput advantage? If so, how much (roughly)?
4) I believe UDP packets are treated as "high priority" but "low reliability". For my application, doesn't that mean that UDP is more likely to cause problems by competing for VoiP and VidCon bandwith?
5) What about trying to write my servers to allow for either UDP or TCP to be
used for data transfer? If you have done this, would you recommend for or against it? Why?
6) If you had to recommend just one book for me for right now (given this project), which would it be:
6a) Java Distributed Computing (O'Reilly) by Jim Farley
6b) Internetworking with TCP/IP by Doug Comer's
6c) Unix Network Programming by Richard Stevens
Being the New Kid on the Block at this company, I need to know all I can as I navigate the politics with this more senior person. I'm no newbie - I've been programming professionally for 27 years, the last 6 in Java including networking, sockets, JDBC, etc.
Thank you very much for your assistance.

Dearest colleagues,
I've done a few hours of research learning what I can
about TCP vs UDP. I could still use some input from
those of you who have used both in real-world,
scaleable, distributed, commercial, and successful
projects.
I have a new position at a new company. My part of
this project consists of 3 types of distributed Java
server programs: desktop client, data server, and
controller server. Thousands of desktop clients will
be periodically transferring "megs" of data to
several data servers. The (singular) controller will
persist metadata into a database, and also coordinate
data transfer between the desktop clients and the
data servers.
TCP seems appropriate for all "control" and metadata
communications between all these components.
Everyone talks to the controller for everything,
, except for the periodic transfer of the "actual"
data. The desktop clients send that data directly to
the appropriate data server using either UDP or TCP.Key feature of TCP is connection orianted and reliablity. If you need long sessions with high reliability TCP is the way to go.
(Long sessions means the client do multiple transaction through same session)
But reliablity of TCP comes at a cost. (Less bandwith efficiency) but of course if you need to transfer data I say TCP is better.
But if you want your clients need to work in unreliable network links (Onse that breakes down often) TCP might cause problems since you have to re establish the connection every time there is a problem.
Also if the sessions are short then UDP is better becouse if you Use TCP for very short sessions Connection establishment and closing can take more time that the actual data transfer.
But if you use UDP you must deal with the unreliability.
One key project requirement is the ability to provide
network throttling control, so as not to saturate the
client's LAN or WAN. This product mustn't disrupt
the client's real-time network data (like VoiP and
video conferencing). I expect the controller server
to manage this.It is true that TCP add more owerhead than UDP but in most cases compaired to the amount of data you transfer through network that is nothing.
Key to save the bandwith is to designe a efficint communication protocol which minimize the amount of data that you have to transfer.
Also you can Implement input/output streams which can limit the number of bytes that can be written or read through them. (Even though that got nothing to do with networking that will give you full control over the bandwidth usage by the programs)
Someone with more seniority than me at this company
has suggested TFTP (which uses UDP) as the best
protocol for the data transfer protocol. This person
also claims that UDP allows larger packet sizes and
less protocol overhead, resulting in greater data
transfer rates than TCP.TFTP is good for transfering small files through networrks since there is less overhead but when it comes to large amounts of data there is no much difference.
But TFTP have a advantage over ureliable networks.
(If the networks fails TCP connection fails, but in UDP a network faliour is just a loss of several datagrams which the programs anyways should be able to handle)
I have a number of concerns and questions:
1) Can't the packet sizes be set for both UDP and
TCP? If so, can't one equal both (in terms of
average overhead) just by adjusting the packet
sizes?In tcp packet size is not a big issue since data are transfered through stream. Once the streams are open you can keep them opena as long as you want and send as many bytes as you want.
2) I realize that one needs to accomodate UDP
droppage in order to compare throughput with TCP. In
a LAN environment is it reasonable to assume that
droppage would be minimal or zero? )Otherwise
wouldn't it be a LAN problem someone would be
fixing?)Even though UPD is said to be unreliable if the programs are written well. In a LAN UDP is almost as areliable as TCP(This is depend on the reliability of LAN)
Thats why it says when you write UDP applications you must test them in slow unreliable Wan links.
3) If #2 above allows me to assume minimal UDP
droppage, does the underlying packet protocol
overhead difference give UDP a substantial throughput
advantage? If so, how much (roughly)?It depends
Ex:-
Lts assume UDB header is 25 bytes and TCP heade is 50 for simplicity
If your data size is 10 byte.
lets say UDP adds overhead of 5 bytes
now the efficiency is 10/(10+25) = 0.38
If TCP adds 10 overhead bytes
now the efficiency is 10/(10+50) = 0.16
lets doa the same calculation for 1000 bytes
UDP
1000/(1000 + 25) = 0.97
TCP
1000/(1000+ 50) = 0.95
So it depends on your application and data volume
4) I believe UDP packets are treated as "high
priority" but "low reliability". For my application,
doesn't that mean that UDP is more likely to cause
problems by competing for VoiP and VidCon bandwith?No Priority is set on IP level so it can be applied to both TCP and UDP
5) What about trying to write my servers to allow
for either UDP or TCP to be
used for data transfer? If you have done this, would
you recommend for or against it? Why?For data transfer I recomend TCP becouse reliability is important.
If you use UDP you have to handle reliability (Lots of programming)
6) If you had to recommend just one book for me for
right now (given this project), which would it be:
6a) Java Distributed Computing (O'Reilly) by Jim
Farley
6b) Internetworking with TCP/IP by Doug Comer's
6c) Unix Network Programming by Richard Stevens
Being the New Kid on the Block at this company, I
need to know all I can as I navigate the politics
with this more senior person. I'm no newbie - I've
been programming professionally for 27 years, the
last 6 in Java including networking, sockets, JDBC,
etc.
Thank you very much for your assistance.

How can i use the SNMP and TCP/IP together in Labview?

I want to use the SNMP and TCP/IP together in the Labview to communicate between the two computers, If anyone know about it , please write back.
Santosh Chavan
IIT MADRAS.

You can use LabVIEWs UDP functions to communicate with SNMP devices. The tedious part is converting the MIB information into the required hex message.
There is also a problem in using the UDP functions on port 161 (default SNMP port) if the Windows SNMP services is running.

How to access OS environment and TCP/IP environment

I'm trying to find a way to access the operating systems commands (I've already figured out how to determine which Windows or which Unix or which Linux I'm in) and TCP/IP commands. In REXX, for example, it's ADDRESS CMD but I don't even have a clue as to what the class would be in Java. Can somebody help, please?
The two kinds of things I'd like to be able to do is issue commands written in whatever language for the environment where the Java program is executing and have the output from these commands come back as a string or series of strings which can then be parsed by the parser we've written for each of the environments we need to deal with (since the same command sometimes results in a different return, depending on the environment where it's running).
For the TCP/IP commands, I'd like to be able to do something like
tcp_ipCommands("ping","www.sun.com");
or
tcp_ipCommands("ping www.sun.com");
depending on how I write it, of course.
Thanks for any light anybody can shed on how to do this.
virginia

Have a Pinger. I can't remember where I stole it from and its from an older API with some deprecated methods. I recall making some 'cosmetic' changes to it at the time and I tested it, so it does work. I've also indicated 2 of the deprecations in the comments.
import java.applet.*;
import java.awt.*;
import java.net.*;
import java.lang.Thread;
// The Pinger object measures network latency by sending a packet
// to the UDP Echo Port (Port 7) and timing how long it takes.
// We use this port instead of ICMP because I would have to
// use native methods in order to produce ICMP packets.
class Pinger implements Runnable{
   static final int echoPort = 7;
   static final int maxPingTime = 3000; // Milliseconds
   static final int pingPollInterval = 100; // Milliseconds
   DatagramSocket socket;
   InetAddress fromIP;
   long sendTime;
   long timeMeasured;
   Thread timeOutMonitor;
   Thread pingListenThread;
   byte packetNumber = 0;
public Pinger(InetAddress pingee){
   fromIP = pingee;
// If needed, start a listener thread to notice the reply.
// then we send out a brief message to the echo port.
// Since the Java thread model does not allow one thread to break
// another one out of a wait, we sleep for brief intervals, waking
// up periodically to see if the reply has come in yet.
public long doPing() {
   byte[] msg = new byte[1];
   msg[0] = ++packetNumber;
   timeMeasured = -1;
      if(socket == null) try {
         socket = new DatagramSocket();
      catch (Exception e) {return(0);}
      if(pingListenThread == null) {
         pingListenThread = new Thread(this);
         pingListenThread.start();
   DatagramPacket packet = new DatagramPacket(msg,msg.length,fromIP,echoPort);
   sendTime = System.currentTimeMillis();
   long timeLimit = sendTime + maxPingTime;
      try {
         socket.send(packet);
            while (System.currentTimeMillis() < timeLimit) {
               Thread.sleep(pingPollInterval);
                  if(timeMeasured != -1) // reply has been noticed, so return result.
            return(timeMeasured);
      catch (Exception e) {};
      return(timeMeasured); // return what is probably -1.
// Run method for the listener thread
public void run() {
byte[] repBuf = new byte[1];
DatagramPacket reply = new DatagramPacket(repBuf,repBuf.length);
   try {
      while (true) {
      socket.receive(reply);
         if(repBuf[0] == packetNumber) {
             timeMeasured = System.currentTimeMillis() - sendTime;
             pingListenThread = null;
             return;
   catch (Exception e) {
      pingListenThread = null; return;
// Clean up any dangling listener thread and release the socket.
public void stop() {
    if(pingListenThread != null) {
        pingListenThread.stop();
        pingListenThread = null;
    socket.close();
    socket = null;
public class PingDisplay extends Applet {
   Pinger ping;
   TextField timeDisplay;
   String fromHost;
   Button refreshButton;
public void init(){
   try {
      fromHost = this.getCodeBase().getHost();
      // Alternative for testing on unrestricted browsers.
      // fromHost = "www.3dcom.com";
      ping = new Pinger(InetAddress.getByName(fromHost));
      timeDisplay = new TextField("Waiting");
      timeDisplay.setEditable(false);
      this.setLayout(new BorderLayout());
      this.add("Center",timeDisplay);
      refreshButton = new Button("Ping");
      refreshButton.resize(40,20);
      this.add("East",refreshButton);
   catch (Exception e) {}
public void start(){
   super.start();
   displayPing();
public void stop(){
   super.stop();
   ping.stop(); // Thread.stop() is depricated but it still works
void displayPing() {
   timeDisplay.setText("Pinging: " + fromHost); // let user know test underway
   long echoTime = ping.doPing(); // conduct actual test
      if(echoTime == -1) // check timeout status
         timeDisplay.setText(fromHost + " timed out.");
      else // display time in button
         timeDisplay.setText("Latency to " + fromHost + ": " + Long.toString(echoTime) + " ms.");
// When "Ping" button pressed, rerun and redisplay.
// Method also depricated here
public boolean action(Event e, Object what) {
   if((e.target == refreshButton) && (e.id == Event.ACTION_EVENT)) {
      displayPing();
      return (true);
   return(false);
}

[solved] problems with timeouts and tcp retransmission

I've recently upgraded my archlinux and am having real problems with the network.
I have checked the configuation and all seems ok.
Everything like DNS/Gateways/IPs all seem to be setup (not changed anything from when it was working before)
I read about setting the MTU manually
ifconfig eth0 mtu 1492
I tried this but it doesn't seem to make any difference
Looking at the packetflow on wireshark it seems that there are a huge amount of TCP Dup ACK and TCP Retransmission when trying to POST
If I boot into windows everything is fine so unfortunately it seems that it might be something with linux
Everything in linux seemed to be working ok before I upgraded
Last edited by equilibrium (2009-12-05 15:13:14)

seems that I am still unable to post from my arch system
$ dmesg | grep sky2
sky2 driver version 1.23
sky2 0000:02:00.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19
sky2 0000:02:00.0: setting latency timer to 64
sky2 0000:02:00.0: Yukon-2 EC chip revision 2
sky2 0000:02:00.0: irq 29 for MSI/MSI-X
sky2 eth0: addr xx:xx:xx:xx:xx:xx
sky2 eth0: enabling interface
sky2 eth0: Link is up at 100 Mbps, full duplex, flow control both
$ ifconfig
eth0 Link encap:Ethernet HWaddr 00:17:31:F4:ED:A2
inet addr:192.168.1.20 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1170 errors:0 dropped:0 overruns:0 frame:0
TX packets:1362 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1101154 (1.0 Mb) TX bytes:197742 (193.1 Kb)
Interrupt:19
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:4595 errors:0 dropped:0 overruns:0 frame:0
TX packets:4595 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:541498 (528.8 Kb) TX bytes:541498 (528.8 Kb)
/etc/rc.conf
eth0="eth0 192.168.1.20 netmask 255.255.255.0 broadcast 192.168.1.255"
INTERFACES=(eth0)
gateway="default gw 192.168.1.1"
ROUTES=(gateway)

Solaris Kernel and TCP/IP Tuning Parameters (Continued)

This page describes some configuration optimizations for Solaris hosts running ATG Page Serving instances (application servers) that will increase server efficiency.
Note that these changes are specific to Solaris systems running ATG application servers (+page serving+ instances). Do not use these on a web server or database server. Those systems require entirely different settings.
h3. Solaris 10 Kernel
Adjust /etc/system (parameters below) and reboot the system.
set rlim_fd_cur=4096
set rlim_fd_max=4096
set tcp:tcp_conn_hash_size=32768
set shmsys:shminfo_shmmax=4294967295
set autoup=900
set tune_t_fsflushr=1h4. Set limits on file descriptors
{color:blue}set rlim_fd_max = 4096{color}
{color:blue}set rlim_fd_cur = 4096{color}
Raise the file-descriptor limits to a maximum of 4096. Note that this tuning option was not mentioned in the "Sun Performance And Tuning" book.
[http://download.oracle.com/docs/cd/E19082-01/819-2724/chapter2-32/index.html]
h4. Increase the connection hash table size
{color:blue}set tcp:tcp_conn_hash_size=8192{color}
Increase the connection hash table size to make look-up's more efficient. The connection hash table size can be set only once, at boot time.
[http://download.oracle.com/docs/cd/E19455-01/816-0607/chapter4-63/index.html]
h4. Increase maximum shared memory segment size
{color:blue}set shmsys:shminfo_shmmax=4294967295{color}
Increase the maximum size of a system V shared memory segment that can be created from roughly 8MB to 4GB.
This provides an adequate ceiling; it does not imply that shared memory segments of this size will be created.
[http://download.oracle.com/docs/cd/E19683-01/816-7137/chapter2-74/index.html]
h4. Increase memory allocated for dirty pages
{color:blue}set autoup=900{color}
Increase the amount of memory examined for dirty pages in each invocation and frequency of file system synchronizing operations.
The value of autoup is also used to control whether a buffer is written out from the free list. Buffers marked with the B_DELWRI flag (which identifies file content pages that have changed) are written out whenever the buffer has been on the list for longer than autoup seconds. Increasing the value of autoup keeps the buffers in memory for a longer time.
[http://download.oracle.com/docs/cd/E19082-01/819-2724/chapter2-16/index.html]
h4. Specify the time between fsflush invocations
Specifies the number of seconds between fsflush invocations.
{color:blue}set tune_t_fsflushr=1{color}
[http://download.oracle.com/docs/cd/E19082-01/819-2724/chapter2-105/index.html]
Again, note that after adjusting any of the preceding kernel parameters you will need to reboot the Solaris server.
h3. TCP
ndd -set /dev/tcp tcp_time_wait_interval 60000
ndd -set /dev/tcp tcp_conn_req_max_q 16384
ndd -set /dev/tcp tcp_conn_req_max_q0 16384
ndd -set /dev/tcp tcp_ip_abort_interval 60000
ndd -set /dev/tcp tcp_keepalive_interval 7200000
ndd -set /dev/tcp tcp_rexmit_interval_initial 4000
ndd -set /dev/tcp tcp_rexmit_interval_max 10000
ndd -set /dev/tcp tcp_rexmit_interval_min 3000
ndd -set /dev/tcp tcp_smallest_anon_port 32768
ndd -set /dev/tcp tcp_xmit_hiwat 131072
ndd -set /dev/tcp tcp_recv_hiwat 131072
ndd -set /dev/tcp tcp_naglim_def 1h4. Tuning the Time Wait Interval and TCP Connection Hash Table Size
{color:blue}/usr/sbin/ndd -set /dev/tcp tcp_time_wait_interval 60000{color}
The tcp_time_wait_interval is how long a connection stays in the TIME_WAIT state after it has been closed (default value 240000 ms or 4 minutes). With the default setting, this socket will remain for 4 minutes after you have closed the FTP connection. This is normal operating behavior. It is done to ensure that any slow packets on the network will arrive before the socket is completely shutdown. As a result, a future program that uses the same socket number won't get confused upon receipt of packets that were intended for the previous program.
On a busy Web server a large backlog of connections waiting to close could build up and the kernel can become inefficient in locating an available TCP data structure. Therefore it is recommended to change this value to 60000 ms or 1 minute.
h4. Tuning the maximum number of requests per IP address per port
{color:blue}ndd -set /dev/tcp tcp_conn_req_max_q 16384{color}
{color:blue}ndd -set /dev/tcp tcp_conn_req_max_q0 16384{color}
The {color:blue}tcp_conn_req_max_q{color} and {color:blue}tcp_conn_req_max_q0{color} parameters are associated with the maximum number of requests that can be accepted per IP address per port. tcp_conn_req_max_q is the maximum number of incoming connections that can be accepted on a port. tcp_conn_req_max_q0 is the maximum number of “half-open” TCP connections that can exist for a port. The parameters are separated in order to allow the administrator to have a mechanism to block SYN segment denial of service attacks on Solaris.
The default values are be too low for a non-trivial web server, messaging server or directory server installation or any server that expects more than 128 concurrent accepts or 4096 concurrent half-opens. Since the ATG application servers are behind a DMZ firewall, we needn't starve these values to ensure against DOS attack.
h4. Tuning the total retransmission timeout value
{color:blue}ndd -set /dev/tcp tcp_ip_abort_interval 60000{color}
{color:blue}tcp_ip_abort_interval{color} specifies the default total retransmission timeout value for a TCP connection. For a given TCP connection, if TCP has been retransmitting for tcp_ip_abort_interval period of time and it has not received any acknowledgment from the other endpoint during this period, TCP closes this connection.
h4. Tuning the Keep Alive interval value
{color:blue}ndd -set /dev/tcp tcp_keepalive_interval 7200000{color}
{color:blue}tcp_keepalive_interval{color} sets a probe interval that is first sent out after a TCP connection is idle on a system-wide basis.
If SO_KEEPALIVE is enabled for a socket, the first keep-alive probe is sent out after a TCP connection is idle for two hours, the default value of the {color:blue}tcp_keepalive_interval{color} parameter. If the peer does not respond to the probe after eight minutes, the TCP connection is aborted.
The {color:blue}tcp_rexmit_interval_*{color} values set the initial, minimum, and maximum retransmission timeout (RTO) values for a TCP connections, in milliseconds.
h4. Tuning the TCP Window Size
{color:blue}/usr/sbin/ndd -set /dev/tcp tcp_xmit_hiwat 65535{color}
{color:blue}/usr/sbin/ndd -set /dev/tcp tcp_recv_hiwat 65535{color}
Setting these two parameters controls the transmit buffer and receive window. We are tuning the kernel to set each window to 65535 bytes. If you set it to 65536 bytes (64K bytes) or more with Solaris 2.6, you trigger the TCP window scale option (RFC1323).
h4. Tuning TCP Slow Start
{color:blue}/usr/sinb/ndd -set /dev/tcp tcp_slow_start_initial 4{color}
tcp_slow_start_initial is the number of packets initially sent until acknowledgment, the congestion window limit.
h4. Tuning the default bytes to buffer
{color:blue}ndd -set /dev/tcp tcp_naglim_def 1{color}
{color:blue}tcp_naglim_def{color} is the default number of bytes to buffer. Each connection has its own copy of this value, which is set to the minimum of the MSS for the connection and the default value. When the application sets the TCP_NODELAY socket option, it changes the connection's copy of this value to 1. The idea behind this algorithm is to reduce the number of small packets transmitted across the wire by introducing a short (100ms) delay for packets smaller than some minimum.
Changing the value of tcp_naglim_def to 1 will have the same effect (on connections established after the change) as if each application set the TCP_NODELAY option.
{note}
The current value of any of the TCP parameters can be displayed with the command ndd get. So to retrieve the current setting of the {color:blue}tcp_naglim_def parameter{color}, simply execute the command:\\
{color:blue}ndd -get /dev/tcp tcp_naglim_def{color}
{note}
h3. References
Solaris Tunable Parameters Reference Manual
[http://download.oracle.com/docs/cd/E19455-01/816-0607/index.html]
WebLogic Server Performance and Tuning
[http://download.oracle.com/docs/cd/E11035_01/wls100/perform/OSTuning.html]

For example,
Socket.setSoTimeout() sets SO_TIMEOUT option and I
want to what TCP parameter this option corresponds in
the underlying TCP connection.This doesn't correspond to anything in the connection, it is an attribute of the API.
The same questions
arises fro other options from SocketOptions class.setTcpNoDelay() controls the Nagle algorithm. set{Send,Receive}BufferSize() controls the local socket buffers.
Most of this is quite adequately described in the javadoc actually.

ACE duplicate ack and tcp out-of-order errors

Hi,
I have just performed a capture using a NAM in my 6500 on the port attached to my ACE appliance.
What i have noticed in the capture is a lot of duplicate ack errors and tcp out-of-sync errors.
The reason we found this was becuase the link utilisation per session seems higher than we expected, hence are the errors adding to this and is there any way to remedy them?
Thanks
Scott

Hi Scott,
I'm not sure why you would see duplicate packets, although when you use SPAN, I know you can see them when you configure it to capture both directions on a VLAN. This is because you see each packet as it enters and leaves the VLAN. I don't know if that would apply to a NAM.
One thing you could do is use the ACE 4710's built-in capture utility to see if you see the same symptoms from an alternative source. This is covered in the Capturing Packet Information section of the configuration guides.
Hope this helps,
Sean

ACE Dup ACK and TCP Out-of-order

Hi,
I have a pair of FT ACE 4710 offloading https traffic to a couple of webservers. We are seeing very high network utilisation when I capture the client facing port of the active ACE. There appears to alot of duplicate ACKs and TCP out-of-order packets (as shown by wireshark). Does anyone know if this is a problem with the ACE or "normal"
Thanks

I've seen some similar behaviour with the ACE Module and Apache webservers. To mitigate this I've configured the following which seems to work.
On the ACE Module
parameter-map type http ALL-HEADERS
persistence-rebalance
parameter-map type connection TCP-OPTIONS
set tcp syn-retry 5
tcp-options timestamp allow
policy-map multi-match test-policy
class http-vip
    loadbalance vip inservice
    loadbalance policy http-test-pm
    loadbalance vip icmp-reply active
    appl-parameter http advanced-options ALL-HEADERS
    connection advanced-options TCP-OPTIONS
On Apache here are the two test results with keepalive on and off
httpd.conf
KeepAlive Off
MaxKeepAliveRequests 1024
KeepAliveTimeout 30
MK-ACE01/001# show serverfarm MK-FARM-sf
serverfarm     : MK-FARM-sf, type: HOST
total rservers : 8
                                                ----------connections-----------
       real                  weight state        current    total      failures
   ---+---------------------+------+------------+----------+----------+---------
   rserver: MK-HOST10
       10.10.1.10:0          8      OPERATIONAL 321        510863     16442
   rserver: MK-HOST11
       10.10.1.11:0          8      OPERATIONAL 304        512718     16276
   rserver: MK-HOST12
       10.10.1.12:0          8      OPERATIONAL 286        524207     17257
   rserver: MK-HOST13
       10.10.1.13:0          8      OPERATIONAL 291        516987     16626
   rserver: MK-HOST14
       10.10.1.14:0          8      OPERATIONAL 291        513016     16594
   rserver: MK-HOST15
       10.10.1.15:0          8      OPERATIONAL 311        510177     16434
   rserver: MK-HOST16
       10.10.1.16:0          8      OPERATIONAL 345        516340     16708
   rserver: MK-HOST17
       10.10.1.17:0          8      OPERATIONAL 282        513046     16418
httpd.conf
KeepAlive On
MaxKeepAliveRequests 1024
KeepAliveTimeout 30
MK-ACE01/001# show serverfarm MK-FARM-sf
serverfarm     : MK-FARM-sf, type: HOST
total rservers : 8
                                                ----------connections-----------
       real                  weight state        current    total      failures
   ---+---------------------+------+------------+----------+----------+---------
   rserver: MK-HOST10
       10.10.1.10:0          8      OPERATIONAL 0          553        0
   rserver: MK-HOST11
       10.10.1.11:0          8      OPERATIONAL 0          551        0
   rserver: MK-HOST12
       10.10.1.12:0          8      OPERATIONAL 0          552        0
   rserver: MK-HOST13
       10.10.1.13:0          8      OPERATIONAL 0          555        0
   rserver: MK-HOST14
       10.10.1.14:0          8      OPERATIONAL 0          554        0
   rserver: MK-HOST15
       10.10.1.15:0          8      OPERATIONAL 0          551        0
   rserver: MK-HOST16
       10.10.1.16:0          8      OPERATIONAL 0          550        0
   rserver: MK-HOST17
       10.10.1.17:0          8      OPERATIONAL 0          550        0
This seems to of reduced the large number or re-transmits and dup-acks.

UDP and TCP

Similar Messages

Maybe you are looking for