Sqlnet tcp window
Are there any Oracle parameters that influence the TCP window size of a sqlnet connection?
Thanks in advance
Hi,
You can check this, may it help you
http://docs.oracle.com/cd/E11882_01/network.112/e10835/sqlnet.htm#BIIDDACA
Similar Messages
-
TCP Window sizing not working as expected for Windows server 2008 R2 SP1
Hi ,
TCP window size is not working as expected. It is varying . Aplied the hotfix suggested by Microsoft and set the multipliccation factor as 1.The window size is not getting auto tuned based on the client machine. The data transfer rate is getting degraded.
Please help.
Thanks,
Pro1962Hi,
I think window auto-tuning is enabled.
You can disable it by running the following commend.
netsh interface tcp set global autotuninglevel=disabled
Hope this helps. -
ACE default handling of the TCP Window Scale option
Can someone tell me a reasonable explanation why the default action of the ACE is to clear the window-scale option in SYN-segments? We were long baffled why some customers (specifically the ones with larger latencies) were suffering from poor TCP transfer speeds and resets. Packet captures confirmed the fact that the ACE was clearing window-scale options, causing the advertised receive windows to be remarkably small as the scaling factors were removed.
Isn't intermediate tampering with the window-scale option a widely known source for TCP performance problems? Window scaling is after all a widely used TCP extension. That's why I'm curious to know why such default behaviour from the ACE.
Our problem was of course finally resolved by explicitly allowing the window-scale option using a parameter map.HI Timo,
As you know if you allows the ACE to use a window scale factor that essentially increases the size of the TCP send and receive buffers. The sender specifies a window scale factor in a SYN segment that determines the send and receive window size for the duration of the connection.
You have defined tcp-options scale allow in the parameter map but have not specified to which scale factor this should scale to.
The TCP window scaling feature adds support for the Window Scaling option in RFC 1323. It is recommend that increasing the window size to improve TCP performance in network paths with large bandwidth, long-delay characteristics. This type of network is called a long fat network (LFN).
But you have not configure a TCP window-scale factor which is essential for network paths with high-bandwidth, long-delay characteristics, using the "set tcp window-scale " command.
The window scaling extension expands the definition of the TCP window to 32 bits and then uses a scale factor to carry this 32-bit value in the 16-bit window field of the TCP header.
You can increase the window size to a maximum scale factor of 14.
Typical applications use a scale factor of 3 when deployed in LFNs but in you case if this is a LFN you are using default which is 0.
So here in your case you can select how much scale factor is needed to be defined from the range 0-14 , otherwise even if you have defined in the tcp-options windlow-scale allow, but as you have not define to what factor it should scale to , so it will always use the default scale factor which is 0, means no scaling at all.
To set the TCP window-scale factor to 3, add the second command as well in your parameter map:
host1/Admin(config-parammap-conn)# tcp-options window-scale allow ---> Defined already
host1/Admin(config-parammap-conn)# set tcp window-scale 3 ----> Needed to be added else "default scale factor 0" will be taken
You can check in the following URL at cisco docs wiki for how ACE handles Connection at Layer 4 (L4) and Layer 7 (L7):
http://docwiki.cisco.com/wiki/Cisco_Application_Control_Engine_(ACE)_Module_Troubleshooting_Guide,_Release_A2(x)_--_Troubleshooting_Connectivity
Here are the details of how a tcp-options scale windows works:
The window scale extension expands the definition of the TCP
window to 32 bits and then uses a scale factor to carry this 32- bit
value in the 16-bit Window field of the TCP header (SEG.WND in RFC-793).
The scale factor is carried in a new TCP option, Window Scale.
This option is sent only in a SYN segment (a segment with the SYN bit on),
hence the window scale is fixed in each direction when a connection is opened.
(Another design choice would be to specify the window scale in every TCP segment.
It would be incorrect to send a window scale option only when the scale factor changed,
since a TCP option in an acknowledgement segment will not be delivered reliably
(unless the ACK happens to be piggy-backed on data in the other direction).
Fixing the scale when the connection is opened has the advantage of lower
overhead but the disadvantage that the scale factor cannot be changed
during the connection.) The maximum receive window, and therefore the
scale factor, is determined by the maximum receive buffer space.
In a typical modern implementation, this maximum buffer space is set
by default but can be overridden by a user program before a
TCP connection is opened. This determines the scale factor,
and therefore no new user interface is needed for window scaling.
Window Scale Option The three-byte Window Scale option
may be sent in a SYN segment by a TCP.
It has two purposes:
(1) indicate that the TCP is prepared to do both send and receive window scaling, and
(2) communicate a scale factor to be applied to its receive window.
Thus, a TCP that is prepared to scale windows should send the option,
even if its own scale factor is 1. The scale factor is limited to
a power of two and encoded logarithmically,
so it may be implemented by binary shift operations.
TCP Window Scale Option (WSopt):
Kind: 3 Length: 3 bytes
+---------+---------+---------+
| Kind=3 |Length=3 |shift.cnt|
+---------+---------+---------+
This option is an offer, not a promise; both sides must send
Window Scale options in their SYN segments to enable window
scaling in either direction. If window scaling is enabled,
then the TCP that sent this option will right-shift its true
receive-window values by 'shift.cnt' bits for transmission in
SEG.WND. The value 'shift.cnt' may be zero (offering to scale,
while applying a scale factor of 1 to the receive window).
This option may be sent in an initial segment (i.e., a
segment with the SYN bit on and the ACK bit off).
It may also be sent in a segment, but only if a Window
Scale op- tion was received in the initial segment.
A Window Scale option in a segment without a SYN bit should be ignored.
The Window field in a SYN (i.e., a or ) segment itself is never scaled.
Using the Window Scale Option
A model implementation of window scaling is as follows
All windows are treated as 32-bit quantities for storage in
the connection control block and for local calculations.
This includes the send-window (SND.WND) and the receive- window
(RCV.WND) values, as well as the congestion window.
* The connection state is augmented by two window shift counts,
Snd.Wind.Scale and Rcv.Wind.Scale, to be applied to the
incoming and outgoing window fields, respectively.
* If a TCP receives a segment containing a Window Scale
option, it sends its own Window Scale option in the segment.
* The Window Scale option is sent with shift.cnt = R, where R
is the value that the TCP would like to use for its receive window.
* Upon receiving a SYN segment with a Window Scale option containing
shift.cnt = S, a TCP sets Snd.Wind.Scale to S and sets Rcv.Wind.Scale
to R; otherwise, it sets both Snd.Wind.Scale and Rcv.Wind.Scale to zero.
* The window field (SEG.WND) in the header of every incoming segment,
with the exception of SYN segments, is left-shifted by Snd.Wind.Scale
bits before updating SND.WND: SND.WND = SEG.WND << Snd.Wind.Scale
(assuming the other conditions of RFC793 are met,
and using the "C" notation "<<" for left-shift).
* The window field (SEG.WND) of every outgoing segment, with the
exception of SYN segments, is right-shifted by
Rcv.Wind.Scale bits: SEG.WND = RCV.WND >> Rcv.Wind.Scale.
TCP determines if a data segment is "old" or "new" by testing
whether its sequence number is within 2**31 bytes of the left
edge of the window, and if it is not, discarding the data as "old".
To insure that new data is never mistakenly considered old and vice- versa,
the left edge of the sender's window has to be at most 2**31 away
from the right edge of the receiver's window. Similarly with the
sender's right edge and receiver's left edge. Since the right and
left edges of either the sender's or receiver's window differ by
the window size, and since the sender and receiver windows can be
out of phase by at most the window size, the above constraints imply
that
2 * the max window size must be less than 2**31,
or max window < 2**30 Since the max window is 2**S
(where S is the scaling shift count) times at most 2**16 - 1
(the maximum unscaled window),
the maximum window is guaranteed to be < 2*30 if S <= 14.
Thus, the shift count must be limited to 14 (which allows windows of 2**30 = 1 Gbyte).
If a Window Scale option is received with a shift.cnt value exceeding 14,
the TCP should log the error but use 14 instead of the specified value.
The scale factor applies only to the Window field as transmitted
in the TCP header; each TCP using extended windows will maintain
the window values locally as 32-bit numbers. For example,
the "congestion window" computed by Slow Start and Congestion Avoidance
is not affected by the scale factor, so window scaling will not introduce
quantization into the congestion window.
Hope it will resolve your issue, else get back to us for further discussion.
Best regards,
Sachin Garg
Message was edited by: sachinga.hcl -
TCP Window Variation Sig fires repeatedly
Sig 1307/0 TCP Window Variation is constantly firing on my IPS. The explanation mentions that some "improperly implemented" firewalls can cause this signature to fire. I have an ASA 5520 between my users and the internet and all internet traffic is NATed. It fires on normal web traffic to known good sites as well as traffic between sites coming in over IPSEC VPN, which is exempted from NAT. Any ideas on what may be causing this?
This signature Sig 1307/0 will fire when the TCP window varies in a suspect manner. The right edge of the recieve window for TCP decreases. The TCP RFCs state that this should not occur.
This signature will NOT function in promiscuous mode.
Some incorrectly implemented proxies or network address translation firewalls could modify the window can cause this signature to fire. -
I have one ACE configured in bridge mode. It is used to load balance between internet proxies.
we also use sticky by source IP address. the internet is working fine with VIP and load is shared between the proxy servers.
we have a problem with one side. it is Http side and also after authentication still be http .
we can open that site if I used any of the proxies IP addresses as a proxy in my browser but when I use the VIP with my proxy setting the site page open and can not authenticate.
when opening the home page of the site I will be redirected to one of teh proxy server ( sticky to my IP ) but after trying to authenticate I can not see any connection opened for my IP .
I tried to sniff packet from my PC I got ( tcp windows size zero ) and connection closed from the ACE.
thanks in advance for your supportHi,
May be
CSCth39502
Regards, -
TCP Window Scaling supported on 3750G and 2960G switches?
We have the 3750G with the IOS version 12.2(35)SE5. Does this IOS version and switch support the TCP Window Scaling detailed in this doc? The doc says Release 12.2(8)T. And I don't see the 3750G or the 2960G platforms listed in the doc. I'm guessing they're not but rather than guess, I thought I'd ask. Thanks
http://www.cisco.com/en/US/docs/ios/12_2t/12_2t8/feature/guide/tcpwslfn.pdfDisclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
The doc says you may see better performance.
Indeed you may, but the doc also notes "Do not use this command unless you clearly understand why you want to change the default value.".
The two common situations where there's possible benefit to increasing the device's TCP receive window are: to allow faster FTP/RCP downloads to the device or to support quicker BGP bulk transfers. The former is limited by write speed to flash and the latter might be unusual to need > 64 KB for BDP.
Also, BTW, if you do find a need to work with scaled TCP receive windows on a Cisco device, you probably also should enable (optional) SACK. -
TCP Window Variation id=1307
Hi, We are getting quite a lot of these alerts and I can't find any info. on the internet. Can anyone shed any light on it.. There are hundreds of these alerts and most of the time the IP adresses are different. As far as I can see most of the time the attacker ip address has been from inside address range. Thanks. Regards
evIdsAlert: eventId=1277786506114716833 vendor=Cisco severity=high
originator:
hostId: abcips1
appName: sensorApp
appInstanceId: 414
time: Oct 06, 2011 05:26:59 UTC offset=0 timeZone=GMT00:00
signature: description=TCP Window Variation id=1307 version=S212 type=anomaly created=20030801
subsigId: 0
sigDetails: TCP Window varied in a suspect way
marsCategory: Info/Misc
interfaceGroup: vs0
vlan: 0
participants:
attacker:
addr: x.x.x.x locality=OUT
port: 39825
target:
addr: x.x.x.x locality=OUT
port: 5667
os: idSource=learned type=linux relevance=relevant
riskRatingValue: 100 targetValueRating=medium attackRelevanceRating=relevant
threatRatingValue: 100
interface: ge0_1
protocol: tcpThanks Mark. We do have an ASA as well as proxy (threat management gateway). I did see link that you posted before I posted my question but its not very clear from the article what can be done to resolve the problem. It says "incorrectly configured" but in what way? It would have been nice if it gave us the possible solutions? or what to check? Thanks. Regards
-
Hi
I captured some TCP comunication because there is a issue with long respons of some application.
I see in some TCP packets using Wireshark:
window size value:593
{Calculated window size: 151808}
{Window size scaling factor: 256}
Can this values indicate some issue?
Or is it correct?
I have other capture when respons of application is OK and there is still the same value "window size value" and "Calculated window size"
Thanks
PeterHi Peter,
The Calculated window size: 151808 as shown above should be fine.
As per RFC 1323:
The TCP header uses a 16 bit field to report the receive
window size to the sender. Therefore, the largest window
that can be used is 2**16 = 65K bytes.
To circumvent this problem, Section 2 of this memo defines a
new TCP option, "Window Scale", to allow windows larger than
2**16. This option defines an implicit scale factor, which
is used to multiply the window size value found in a TCP
header to obtain the true window size.
Hope this helps.
Thanks,
Rajesh. -
Windows TCP Socket Buffer Hitting Plateau Too Early
Note: This is a repost of a ServerFault Question edited over the course of a few days, originally here: http://serverfault.com/questions/608060/windows-tcp-window-scaling-hitting-plateau-too-early
Scenario: We have a number of Windows clients regularly uploading large files (FTP/SVN/HTTP PUT/SCP) to Linux servers that are ~100-160ms away. We have 1Gbit/s synchronous bandwidth at the office and the servers are either AWS instances or physically hosted
in US DCs.
The initial report was that uploads to a new server instance were much slower than they could be. This bore out in testing and from multiple locations; clients were seeing stable 2-5Mbit/s to the host from their Windows systems.
I broke out iperf
-s on a an AWS instance and then from a Windows client in the office:
iperf
-c 1.2.3.4
[ 5] local 10.169.40.14 port 5001 connected with 1.2.3.4 port 55185
[ 5] 0.0-10.0 sec 6.55 MBytes 5.48 Mbits/sec
iperf
-w1M -c 1.2.3.4
[ 4] local 10.169.40.14 port 5001 connected with 1.2.3.4 port 55239
[ 4] 0.0-18.3 sec 196 MBytes 89.6 Mbits/sec
The latter figure can vary significantly on subsequent tests, (Vagaries of AWS) but is usually between 70 and 130Mbit/s which is more than enough for our needs. Wiresharking the session, I can see:
iperf
-c Windows SYN - Window 64kb, Scale 1 - Linux SYN, ACK: Window 14kb, Scale: 9 (*512)
iperf
-c -w1M Windows SYN - Windows 64kb, Scale 1 - Linux SYN, ACK: Window 14kb, Scale: 9
Clearly the link can sustain this high throughput, but I have to explicity set the window size to make any use of it, which most real world applications won't let me do. The TCP handshakes use the same starting points in each case, but the forced one scales
Conversely, from a Linux client on the same network a straight, iperf
-c (using the system default 85kb) gives me:
[ 5] local 10.169.40.14 port 5001 connected with 1.2.3.4 port 33263
[ 5] 0.0-10.8 sec 142 MBytes 110 Mbits/sec
Without any forcing, it scales as expected. This can't be something in the intervening hops or our local switches/routers and seems to affect Windows 7 and 8 clients alike. I've read lots of guides on auto-tuning, but these are typically about disabling scaling
altogether to work around bad terrible home networking kit.
Can anyone tell me what's happening here and give me a way of fixing it? (Preferably something I can stick in to the registry via GPO.)
Notes
The AWS Linux instance in question has the following kernel settings applied in sysctl.conf:
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.core.rmem_default = 1048576
net.core.wmem_default = 1048576
net.ipv4.tcp_rmem = 4096 1048576 16777216
net.ipv4.tcp_wmem = 4096 1048576 16777216
I've used dd
if=/dev/zero | nc redirecting to /dev/null at
the server end to rule out iperfand
remove any other possible bottlenecks, but the results are much the same. Tests with ncftp(Cygwin,
Native Windows, Linux) scale in much the same way as the above iperf tests on their respective platforms.
First fix attempts.
Enabling CTCP - This makes no difference; window scaling is identical. (If I understand this correctly, this setting increases the rate at which the congestion window is enlarged rather than the maximum size it can reach)
Enabling TCP timestamps. - No change here either.
Nagle's algorithm - That makes sense and at least it means I can probably ignore that particular blips in the graph as any indication of the problem.
pcap files: Zip file available here: https://www.dropbox.com/s/104qdysmk01lnf6/iperf-pcaps-10s-Win%2BLinux-2014-06-30.zip (Anonymised
with bittwiste, extracts to ~150MB as there's one from each OS client for comparison)
Second fix attempts.
I've enabled ctcp and disabled chimney offloading: TCP Global Parameters
Receive-Side Scaling State : enabled
Chimney Offload State : disabled
NetDMA State : enabled
Direct Cache Acess (DCA) : disabled
Receive Window Auto-Tuning Level : normal
Add-On Congestion Control Provider : ctcp
ECN Capability : disabled
RFC 1323 Timestamps : enabled
Initial RTO : 3000
Non Sack Rtt Resiliency : disabled
But sadly, no change in the throughput.
I do have a cause/effect question here, though: The graphs are of the RWIN value set in the server's ACKs to the client. With Windows clients, am I right in thinking that Linux isn't scaling this value beyond that low point because the client's limited CWIN
prevents even that buffer from being filled? Could there be some other reason that Linux is artificially limiting the RWIN?
Note: I've tried turning on ECN for the hell of it; but no change, there.
Third fix attempts.
No change following disabling heuristics and RWIN autotuning. Have updated the Intel network drivers to the latest (12.10.28.0) with software that exposes functioanlity tweaks viadevice manager tabs. The card is an 82579V Chipset on-board NIC - (I'm going to
do some more testing from clients with realtek or other vendors)
Focusing on the NIC for a moment, I've tried the following (Mostly just ruling out unlikely culprits):
Increase receive buffers to 2k from 256 and transmit buffers to 2k from 512 (Both now at maximum) - No change
Disabled all IP/TCP/UDP checksum offloading. - No change.
Disabled Large Send Offload - Nada.
Turned off IPv6, QoS scheduling - Nowt.
Further investigation
Trying to eliminate the Linux server side, I started up a Server 2012R2 instance and repeated the tests using iperf (cygwin
binary) and NTttcp.
With iperf,
I had to explicitly specify -w1m on both sides
before the connection would scale beyond ~5Mbit/s. (Incidentally, I could be checked and the BDP of ~5Mbits at 91ms latency is almost precisely 64kb. Spot the limit...)
The ntttcp binaries showed now such limitation. Using ntttcpr
-m 1,0,1.2.3.5 on the server and ntttcp
-s -m 1,0,1.2.3.5 -t 10 on the client, I can see much better throughput:
Copyright Version 5.28
Network activity progressing...
Thread Time(s) Throughput(KB/s) Avg B / Compl
====== ======= ================ =============
0 9.990 8155.355 65536.000
##### Totals: #####
Bytes(MEG) realtime(s) Avg Frame Size Throughput(MB/s)
================ =========== ============== ================
79.562500 10.001 1442.556 7.955
Throughput(Buffers/s) Cycles/Byte Buffers
===================== =========== =============
127.287 308.256 1273.000
DPCs(count/s) Pkts(num/DPC) Intr(count/s) Pkts(num/intr)
============= ============= =============== ==============
1868.713 0.785 9336.366 0.157
Packets Sent Packets Received Retransmits Errors Avg. CPU %
============ ================ =========== ====== ==========
57833 14664 0 0 9.476
8MB/s puts it up at the levels I was getting with explicitly large windows in iperf.
Oddly, though, 80MB in 1273 buffers = a 64kB buffer again. A further wireshark shows a good, variable RWIN coming back from the server (Scale factor 256) that the client seems to fulfil; so perhaps ntttcp is misreporting the send window.
Further PCAP files have been provided, here:https://www.dropbox.com/s/dtlvy1vi46x75it/iperf%2Bntttcp%2Bftp-pcaps-2014-07-03.zip
Two more iperfs,
both from Windows to the same Linux server as before (1.2.3.4): One with a 128k Socket size and default 64k window (restricts to ~5Mbit/s again) and one with a 1MB send window and default 8kb socket size. (scales higher)
One ntttcp trace
from the same Windows client to a Server 2012R2 EC2 instance (1.2.3.5). here, the throughput scales well. Note: NTttcp does something odd on port 6001 before it opens the test connection. Not sure what's happening there.
One FTP data trace, uploading 20MB of /dev/urandom to
a near identical linux host (1.2.3.6) using Cygwin ncftp.
Again the limit is there. The pattern is much the same using Windows Filezilla.
Changing the iperf buffer
length does make the expected difference to the time sequence graph (much more vertical sections), but the actual throughput is unchanged.
So we have a final question through all of this: Where is this limitation creeping in? If we simply have user-space software not written to take advantage of Long Fat Networks, can anything be done in the OS to improve the situation?Hi,
Thanks for posting in Microsoft TechNet forums.
I will try to involve someone familiar with this topic to further look at this issue. There might be some time delay. Appreciate your patience.
Thank you for your understanding and support.
Kate Li
TechNet Community Support -
TCP Timeouts in Native Windows 7 64-bit (wired and wireless)
I am having some major headaches with this new laptop in regards to network stability. I have a W510 4318CTO with the Ultimate-N 6300 AGN adapter. Here is what I'm seeing:
Prior to installing Virtual PC/XP Mode, whenever I am browsing the web or accessing samba shares, I occasionally get spurts of timeouts. Sometimes the timeouts are inescapable, but oddly enough the issue surfaces less after a hibernation than after a reboot or shutdown/start. Google Docs is one thing that is especially unstable. Either the icons don't load or the style sheet doesn't load or I can't click on anything or I can't save a document or open a document. This happens across all browsers when run in regular old Windows 7. I tried adjusting affinity and resetting tcp and reinstalling the network drivers and scanning for malware and yada yada yada.
I have made queries on Microsoft Connect and TechSupportForum and nothing I've tried is helping. This problem doesn't happen on my XP desktop at all, and very strangely, this doesn't happen in XP Mode on the same laptop at the same time as the issue surfaces in native win7. If I ping the gateway, I get timeouts at the same time as the issue manifests and I get longer response times when making network requests. I have been hammering this issue for the entire month and can't get past it. I've tried uninstalling Lenovo's Access Connection tool and that didn't help either. I tried this over the 82577LM gigabit wired adapter as well and have the same issues but they occur less than in wireless mode (which I would expect).
I am quite an expert on Windows, but this issue has brought me to my wits end. I am an inch away from blowing the preinstall away and starting from scratch, but I just don't want to invest so much time in reinstalling everything. I've had enough trouble with working around power management issues on this new laptop and I just want this fixed.
If you can solve this, I would be forever grateful. I feel like I'm in the empty hell of a network admin's nightmare.
- SteveHello,
If go into the Device Manager (filename: DEVMGMT.MSC), select View→Show Hidden Devices and examine the Non-Plug and Play Drivers tree, are there any old device drivers left over from previously installed security or connectivity software? If so, perhaps one of those is the culprit and disabling or uninstalling it will solve the problem.
Another possibility is that the automatic network tuning enhancements (a feature first introduced in Windows Vista) in Windows 7's network stack are changing the TCP window size until it reaches a value which is incompatible with your router. That is fairly simple to test, though: Open an elevated Command Prompt (filename: CMD.EXE) and issue a "netsh int tcp set global autotuninglevel=disabled" command and see if that makes any difference. If that makes no difference, repeat the Netsh command with "autotuning=enabled" to restore the previous values and we can continue troubleshooting.
Regards,
Aryeh Goretsky
I am a volunteer and neither a Lenovo nor a Microsoft employee. • Dexter is a good dog • Dexter je dobrý pes
S230u (3347-4HU) • X220 (4286-CTO) • W510 (4318-CTO) • W530 (2441-4R3) • X100e (3508-CTO) • X120e (0596-CTO) • T61p (6459-CTO) • T43p (2678-H7U) • T42 (2378-R4U) • T23 (2648-LU7)
Deutsche Community Comunidad en Español Русскоязычное Сообщество -
In AIR 3.x, a socket write() + flush() on a client will hang (and freeze the entire app) if the socket peer advertises a ZERO TCP Window, i.e. no space available in peer receiver's socket buffer.
AIR on Windows insists that the developer flush() the socket in order to write (any data at all). When the peer (receiver) advertises a 0 byte tcp window, the client flush() call can sometimes take 10 seconds (i.e. 10000 milliseconds), whereas normally it should take 10 to 50 milliseconds.
Additionally, AIR stayed in hung position. Since the socket had TCP KEEPALIVE option enabled (at the server), the socket stayed open. I let it stay hung overnight. The next day when I rebooted the server, the socket got closed and finally the AIR program "RETURNED FROM the sock.flush()" call. A timestamp before and after the call to flush() showed that the flush() call was in hung state for 56472475 milliseconds, i.e. 15.7 hours! After it returned from the flush() call the AIR app was responsive and seemed to work properly. Thus proving that it was indeed stuck (or blocked) on the flush() call for 15 hours trying to drain the data to a socket with zero tcp window condition.
A tcp zero window condition on 1 socket hanging an entire app sounds concerning.
Solution Suggestions:
(1) What is needed is for the OutputProgress event to include a field for 'bytes that can be written safely without blocking on the socket', i.e. 'space available in underlying platform socket buffer' which would account for the socket send buffer size.
(2) An alternative solution would be for AIR to provide a write-timeout setsockopt (or a writeTimeout() method on the socket), and return flush with an error (or EWOULDBLOCK), and call the OUTPUTPROG event only when there is enough space available.
If there are any other workarounds, please let me know.
Thank you.Question: Does Adobe AIR expose the getsockopt() and setsockopt() calls on a socket? It would be useful to apps to tune the io buffer sizes.
Additional Details:
RTT = 100+ milliseconds
TCP Window Scaling enabled
Secure Socket
Hard to reproduce with plain TCP socket, but occurs without fail with SecureSocket. Not knowing the underlying code base, am wondering if it is because the SSL encryption overhead (bytes) throws off the buffer available size compution in secure_sock.flush() .
Thanks. -
Non-global zone sending TCP SYN-ACK packet over wrong interface.
After spending many hours looking at ipmon/ethereal logs, I believe I've found
a explanation (a bug?) for the following strange behaviour (Solaris 10u1):
I've got a non-global zone with Apache2 with dedicated IP and bound to interface e1000g2 of a Sun X4200 box. The global zone has a different dedicated IP bound to a different interface e1000g0.
When I point a browser at the web site, the HTML page often comes up immediately, but sometimes it will hang and only load when I press the reload browser button one or multiple times. This is reproducible with different browsers from different networks with or without DNS resolution. It's reproducible with other non-local zones configured alike and running different TCP based services (namely SSH or non-Apache HTTP).
This is what happens in a failing case (Ethereal client dump "dump_failed.txt" and IPF log "att1.txt" lines 1-3 pp): the incoming TCP SYN comes over interface e1000g2 (correct) and is passed by IPF. However, the non-global zone sends the TCP SYN-ACK package back over interface e1000g0, which is wrong and causes IPF to fail to build a correct state entry. Then, afterwards, the response packets from the webserver will be filtered by IPF, since it has no state entry.
In the success case (Ethereal client dump "dump_success.txt" and IPF log "att1.txt" lines 19-21 pp), the incoming TCP SYN is answered correctly by a TCP SYN-ACK both over interface e1000g2. IPF can build a state entry and all subsequent packets from the webserver reach the client.
=====
The non-global zone has this setup:
zonecfg:ws1> info
...snip...
net:
address: 62.146.25.34
physical: e1000g2
zonecfg:ws1>
=====
The relevant (as of the IPF log) IPF rules are:
rule 1: block out log all
rule 16: pass in log quick proto tcp from any to 62.146.25.34 port = 80 keep state
=====
If I didn't miss an important point, I suspect this to be a bug in Zones and/or IPF.
Any hints?
Thx,
Tobias
"att1.txt":
LINE PACKET_DT PACKET_FS PACKET_IFC RULE_NUMBER RULE_ACTION SOURCE_IP SOURCE_PORT DEST_IP DEST_PORT PROTOCOL TCP_FLAGS
1 08.05.2006 21:24:09 786741 e1000g2 16 p 84.56.16.159 60693 62.146.25.34 80 tcp S
2 08.05.2006 21:24:09 786863 e1000g0 16 p 62.146.25.34 80 84.56.16.159 60693 tcp AS
3 08.05.2006 21:24:09 808218 e1000g2 16 p 84.56.16.159 60693 62.146.25.34 80 tcp A
4 08.05.2006 21:24:09 837170 e1000g2 16 p 84.56.16.159 60693 62.146.25.34 80 tcp AP
5 08.05.2006 21:24:09 837189 e1000g2 1 b 62.146.25.34 80 84.56.16.159 60693 tcp A
6 08.05.2006 21:24:09 837479 e1000g2 1 b 62.146.25.34 80 84.56.16.159 60693 tcp AP
7 08.05.2006 21:24:12 823801 e1000g2 16 p 84.56.16.159 60693 62.146.25.34 80 tcp AP
8 08.05.2006 21:24:12 823832 e1000g2 1 b 62.146.25.34 80 84.56.16.159 60693 tcp A
9 08.05.2006 21:24:13 210039 e1000g2 1 b 62.146.25.34 80 84.56.16.159 60693 tcp AP
10 08.05.2006 21:24:18 839318 e1000g2 16 p 84.56.16.159 60693 62.146.25.34 80 tcp AP
11 08.05.2006 21:24:18 839351 e1000g2 1 b 62.146.25.34 80 84.56.16.159 60693 tcp A
12 08.05.2006 21:24:19 970040 e1000g2 1 b 62.146.25.34 80 84.56.16.159 60693 tcp AP
13 08.05.2006 21:24:24 840073 e1000g2 1 b 62.146.25.34 80 84.56.16.159 60693 tcp AF
14 08.05.2006 21:24:30 870503 e1000g2 16 p 84.56.16.159 60693 62.146.25.34 80 tcp AP
15 08.05.2006 21:24:30 870538 e1000g2 1 b 62.146.25.34 80 84.56.16.159 60693 tcp A
16 08.05.2006 21:24:33 480059 e1000g2 1 b 62.146.25.34 80 84.56.16.159 60693 tcp AFP
17 08.05.2006 21:24:45 347464 e1000g2 16 p 84.56.16.159 60693 62.146.25.34 80 tcp AF
18 08.05.2006 21:24:45 347498 e1000g2 1 b 62.146.25.34 80 84.56.16.159 60693 tcp A
19 08.05.2006 21:24:47 857068 e1000g2 16 p 84.56.16.159 60694 62.146.25.34 80 tcp S
20 08.05.2006 21:24:47 857118 e1000g2 16 p 62.146.25.34 80 84.56.16.159 60694 tcp AS
21 08.05.2006 21:24:47 878257 e1000g2 16 p 84.56.16.159 60694 62.146.25.34 80 tcp A
22 08.05.2006 21:24:47 907630 e1000g2 16 p 84.56.16.159 60694 62.146.25.34 80 tcp AP
23 08.05.2006 21:24:47 907644 e1000g2 16 p 62.146.25.34 80 84.56.16.159 60694 tcp A
24 08.05.2006 21:24:47 907892 e1000g2 16 p 62.146.25.34 80 84.56.16.159 60694 tcp AP
25 08.05.2006 21:24:47 976361 e1000g2 16 p 84.56.16.159 60694 62.146.25.34 80 tcp AP
26 08.05.2006 21:24:47 976375 e1000g2 16 p 62.146.25.34 80 84.56.16.159 60694 tcp A
27 08.05.2006 21:24:47 976487 e1000g2 16 p 62.146.25.34 80 84.56.16.159 60694 tcp AP
28 08.05.2006 21:24:48 127599 e1000g2 16 p 84.56.16.159 60694 62.146.25.34 80 tcp A
29 08.05.2006 21:24:54 932569 e1000g2 16 p 84.56.16.159 60693 62.146.25.34 80 tcp AFP
30 08.05.2006 21:24:54 932595 e1000g2 1 b 62.146.25.34 80 84.56.16.159 60693 tcp A
31 08.05.2006 21:25:00 490052 e1000g2 1 b 62.146.25.34 80 84.56.16.159 60693 tcp AFP
32 08.05.2006 21:25:02 980057 e1000g2 16 p 62.146.25.34 80 84.56.16.159 60694 tcp AF
33 08.05.2006 21:25:03 1890 e1000g2 16 p 84.56.16.159 60694 62.146.25.34 80 tcp A
34 08.05.2006 21:25:09 907916 e1000g2 16 p 84.56.16.159 60694 62.146.25.34 80 tcp AF
35 08.05.2006 21:25:09 907949 e1000g2 16 p 62.146.25.34 80 84.56.16.159 60694 tcp A
36 08.05.2006 21:25:42 948502 e1000g2 16 p 84.56.16.159 60693 62.146.25.34 80 tcp AFP
37 08.05.2006 21:25:42 948535 e1000g2 1 b 62.146.25.34 80 84.56.16.159 60693 tcp A
38 08.05.2006 21:25:54 500051 e1000g2 1 b 62.146.25.34 80 84.56.16.159 60693 tcp AFP
39 08.05.2006 21:26:54 510046 e1000g2 1 b 62.146.25.34 80 84.56.16.159 60693 tcp AFP
40 08.05.2006 21:27:54 520041 e1000g2 1 b 62.146.25.34 80 84.56.16.159 60693 tcp AFP
41 08.05.2006 21:28:54 530040 e1000g2 1 b 62.146.25.34 80 84.56.16.159 60693 tcp AFP
42 08.05.2006 21:29:54 540039 e1000g2 1 b 62.146.25.34 80 84.56.16.159 60693 tcp AFP
43 08.05.2006 21:30:54 550039 e1000g2 1 b 62.146.25.34 80 84.56.16.159 60693 tcp AFP
44 08.05.2006 21:31:54 560041 e1000g2 1 b 62.146.25.34 80 84.56.16.159 60693 tcp AFP
"dump_failed.txt":
No. Time Source Destination Protocol Info
1 0.000000 192.168.1.101 62.146.25.34 TCP 1079 > http [SYN] Seq=0 Len=0 MSS=1460
Frame 1 (62 bytes on wire, 62 bytes captured)
Ethernet II, Src: FujitsuS_81:79:ea (00:30:05:81:79:ea), Dst: D-Link_9b:09:44 (00:0d:88:9b:09:44)
Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 62.146.25.34 (62.146.25.34)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 48
Identification: 0x0269 (617)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 128
Protocol: TCP (0x06)
Header checksum: 0xde9d [correct]
Source: 192.168.1.101 (192.168.1.101)
Destination: 62.146.25.34 (62.146.25.34)
Transmission Control Protocol, Src Port: 1079 (1079), Dst Port: http (80), Seq: 0, Len: 0
Source port: 1079 (1079)
Destination port: http (80)
Sequence number: 0 (relative sequence number)
Header length: 28 bytes
Flags: 0x0002 (SYN)
Window size: 65535
Checksum: 0x5c3c [correct]
Options: (8 bytes)
No. Time Source Destination Protocol Info
2 0.022698 62.146.25.34 192.168.1.101 TCP http > 1079 [SYN, ACK] Seq=0 Ack=1 Win=49368 Len=0 MSS=1452
Frame 2 (62 bytes on wire, 62 bytes captured)
Ethernet II, Src: D-Link_9b:09:44 (00:0d:88:9b:09:44), Dst: FujitsuS_81:79:ea (00:30:05:81:79:ea)
Internet Protocol, Src: 62.146.25.34 (62.146.25.34), Dst: 192.168.1.101 (192.168.1.101)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 48
Identification: 0x002f (47)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 50
Protocol: TCP (0x06)
Header checksum: 0x2ed8 [correct]
Source: 62.146.25.34 (62.146.25.34)
Destination: 192.168.1.101 (192.168.1.101)
Transmission Control Protocol, Src Port: http (80), Dst Port: 1079 (1079), Seq: 0, Ack: 1, Len: 0
Source port: http (80)
Destination port: 1079 (1079)
Sequence number: 0 (relative sequence number)
Acknowledgement number: 1 (relative ack number)
Header length: 28 bytes
Flags: 0x0012 (SYN, ACK)
Window size: 49368
Checksum: 0xd017 [correct]
Options: (8 bytes)
No. Time Source Destination Protocol Info
3 0.022749 192.168.1.101 62.146.25.34 TCP 1079 > http [ACK] Seq=1 Ack=1 Win=65535 [TCP CHECKSUM INCORRECT] Len=0
Frame 3 (54 bytes on wire, 54 bytes captured)
Ethernet II, Src: FujitsuS_81:79:ea (00:30:05:81:79:ea), Dst: D-Link_9b:09:44 (00:0d:88:9b:09:44)
Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 62.146.25.34 (62.146.25.34)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 40
Identification: 0x026a (618)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 128
Protocol: TCP (0x06)
Header checksum: 0xdea4 [correct]
Source: 192.168.1.101 (192.168.1.101)
Destination: 62.146.25.34 (62.146.25.34)
Transmission Control Protocol, Src Port: 1079 (1079), Dst Port: http (80), Seq: 1, Ack: 1, Len: 0
Source port: 1079 (1079)
Destination port: http (80)
Sequence number: 1 (relative sequence number)
Acknowledgement number: 1 (relative ack number)
Header length: 20 bytes
Flags: 0x0010 (ACK)
Window size: 65535
Checksum: 0x19dc [incorrect, should be 0xbdac]
No. Time Source Destination Protocol Info
4 0.022919 192.168.1.101 62.146.25.34 HTTP GET / HTTP/1.1
Frame 4 (476 bytes on wire, 476 bytes captured)
Ethernet II, Src: FujitsuS_81:79:ea (00:30:05:81:79:ea), Dst: D-Link_9b:09:44 (00:0d:88:9b:09:44)
Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 62.146.25.34 (62.146.25.34)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 462
Identification: 0x026b (619)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 128
Protocol: TCP (0x06)
Header checksum: 0xdcfd [correct]
Source: 192.168.1.101 (192.168.1.101)
Destination: 62.146.25.34 (62.146.25.34)
Transmission Control Protocol, Src Port: 1079 (1079), Dst Port: http (80), Seq: 1, Ack: 1, Len: 422
Source port: 1079 (1079)
Destination port: http (80)
Sequence number: 1 (relative sequence number)
Next sequence number: 423 (relative sequence number)
Acknowledgement number: 1 (relative ack number)
Header length: 20 bytes
Flags: 0x0018 (PSH, ACK)
Window size: 65535
Checksum: 0x1b82 [incorrect, should be 0xcda5]
Hypertext Transfer Protocol
No. Time Source Destination Protocol Info
5 3.013084 192.168.1.101 62.146.25.34 HTTP [TCP Retransmission] GET / HTTP/1.1
Frame 5 (476 bytes on wire, 476 bytes captured)
Ethernet II, Src: FujitsuS_81:79:ea (00:30:05:81:79:ea), Dst: D-Link_9b:09:44 (00:0d:88:9b:09:44)
Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 62.146.25.34 (62.146.25.34)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 462
Identification: 0x0276 (630)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 128
Protocol: TCP (0x06)
Header checksum: 0xdcf2 [correct]
Source: 192.168.1.101 (192.168.1.101)
Destination: 62.146.25.34 (62.146.25.34)
Transmission Control Protocol, Src Port: 1079 (1079), Dst Port: http (80), Seq: 1, Ack: 1, Len: 422
Source port: 1079 (1079)
Destination port: http (80)
Sequence number: 1 (relative sequence number)
Next sequence number: 423 (relative sequence number)
Acknowledgement number: 1 (relative ack number)
Header length: 20 bytes
Flags: 0x0018 (PSH, ACK)
Window size: 65535
Checksum: 0x1b82 [incorrect, should be 0xcda5]
SEQ/ACK analysis
Hypertext Transfer Protocol
No. Time Source Destination Protocol Info
6 9.029003 192.168.1.101 62.146.25.34 HTTP [TCP Retransmission] GET / HTTP/1.1
Frame 6 (476 bytes on wire, 476 bytes captured)
Ethernet II, Src: FujitsuS_81:79:ea (00:30:05:81:79:ea), Dst: D-Link_9b:09:44 (00:0d:88:9b:09:44)
Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 62.146.25.34 (62.146.25.34)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 462
Identification: 0x027f (639)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 128
Protocol: TCP (0x06)
Header checksum: 0xdce9 [correct]
Source: 192.168.1.101 (192.168.1.101)
Destination: 62.146.25.34 (62.146.25.34)
Transmission Control Protocol, Src Port: 1079 (1079), Dst Port: http (80), Seq: 1, Ack: 1, Len: 422
Source port: 1079 (1079)
Destination port: http (80)
Sequence number: 1 (relative sequence number)
Next sequence number: 423 (relative sequence number)
Acknowledgement number: 1 (relative ack number)
Header length: 20 bytes
Flags: 0x0018 (PSH, ACK)
Window size: 65535
Checksum: 0x1b82 [incorrect, should be 0xcda5]
SEQ/ACK analysis
Hypertext Transfer Protocol
No. Time Source Destination Protocol Info
7 21.060827 192.168.1.101 62.146.25.34 HTTP [TCP Retransmission] GET / HTTP/1.1
Frame 7 (476 bytes on wire, 476 bytes captured)
Ethernet II, Src: FujitsuS_81:79:ea (00:30:05:81:79:ea), Dst: D-Link_9b:09:44 (00:0d:88:9b:09:44)
Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 62.146.25.34 (62.146.25.34)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 462
Identification: 0x0284 (644)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 128
Protocol: TCP (0x06)
Header checksum: 0xdce4 [correct]
Source: 192.168.1.101 (192.168.1.101)
Destination: 62.146.25.34 (62.146.25.34)
Transmission Control Protocol, Src Port: 1079 (1079), Dst Port: http (80), Seq: 1, Ack: 1, Len: 422
Source port: 1079 (1079)
Destination port: http (80)
Sequence number: 1 (relative sequence number)
Next sequence number: 423 (relative sequence number)
Acknowledgement number: 1 (relative ack number)
Header length: 20 bytes
Flags: 0x0018 (PSH, ACK)
Window size: 65535
Checksum: 0x1b82 [incorrect, should be 0xcda5]
SEQ/ACK analysis
Hypertext Transfer Protocol
No. Time Source Destination Protocol Info
8 35.561984 192.168.1.101 62.146.25.34 TCP 1079 > http [FIN, ACK] Seq=423 Ack=1 Win=65535 [TCP CHECKSUM INCORRECT] Len=0
Frame 8 (54 bytes on wire, 54 bytes captured)
Ethernet II, Src: FujitsuS_81:79:ea (00:30:05:81:79:ea), Dst: D-Link_9b:09:44 (00:0d:88:9b:09:44)
Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 62.146.25.34 (62.146.25.34)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 40
Identification: 0x029a (666)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 128
Protocol: TCP (0x06)
Header checksum: 0xde74 [correct]
Source: 192.168.1.101 (192.168.1.101)
Destination: 62.146.25.34 (62.146.25.34)
Transmission Control Protocol, Src Port: 1079 (1079), Dst Port: http (80), Seq: 423, Ack: 1, Len: 0
Source port: 1079 (1079)
Destination port: http (80)
Sequence number: 423 (relative sequence number)
Acknowledgement number: 1 (relative ack number)
Header length: 20 bytes
Flags: 0x0011 (FIN, ACK)
Window size: 65535
Checksum: 0x19dc [incorrect, should be 0xbc05]
"dump_success.txt":
No. Time Source Destination Protocol Info
1 0.000000 192.168.1.101 62.146.25.34 TCP 1083 > http [SYN] Seq=0 Len=0 MSS=1460
Frame 1 (62 bytes on wire, 62 bytes captured)
Ethernet II, Src: FujitsuS_81:79:ea (00:30:05:81:79:ea), Dst: D-Link_9b:09:44 (00:0d:88:9b:09:44)
Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 62.146.25.34 (62.146.25.34)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 48
Identification: 0x02a3 (675)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 128
Protocol: TCP (0x06)
Header checksum: 0xde63 [correct]
Source: 192.168.1.101 (192.168.1.101)
Destination: 62.146.25.34 (62.146.25.34)
Transmission Control Protocol, Src Port: 1083 (1083), Dst Port: http (80), Seq: 0, Len: 0
Source port: 1083 (1083)
Destination port: http (80)
Sequence number: 0 (relative sequence number)
Header length: 28 bytes
Flags: 0x0002 (SYN)
Window size: 65535
Checksum: 0x70ca [correct]
Options: (8 bytes)
No. Time Source Destination Protocol Info
2 0.020553 62.146.25.34 192.168.1.101 TCP http > 1083 [SYN, ACK] Seq=0 Ack=1 Win=49368 Len=0 MSS=1452
Frame 2 (62 bytes on wire, 62 bytes captured)
Ethernet II, Src: D-Link_9b:09:44 (00:0d:88:9b:09:44), Dst: FujitsuS_81:79:ea (00:30:05:81:79:ea)
Internet Protocol, Src: 62.146.25.34 (62.146.25.34), Dst: 192.168.1.101 (192.168.1.101)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 48
Identification: 0x006b (107)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 50
Protocol: TCP (0x06)
Header checksum: 0x2e9c [correct]
Source: 62.146.25.34 (62.146.25.34)
Destination: 192.168.1.101 (192.168.1.101)
Transmission Control Protocol, Src Port: http (80), Dst Port: 1083 (1083), Seq: 0, Ack: 1, Len: 0
Source port: http (80)
Destination port: 1083 (1083)
Sequence number: 0 (relative sequence number)
Acknowledgement number: 1 (relative ack number)
Header length: 28 bytes
Flags: 0x0012 (SYN, ACK)
Window size: 49368
Checksum: 0xb530 [correct]
Options: (8 bytes)
No. Time Source Destination Protocol Info
3 0.020599 192.168.1.101 62.146.25.34 TCP 1083 > http [ACK] Seq=1 Ack=1 Win=65535 [TCP CHECKSUM INCORRECT] Len=0
Frame 3 (54 bytes on wire, 54 bytes captured)
Ethernet II, Src: FujitsuS_81:79:ea (00:30:05:81:79:ea), Dst: D-Link_9b:09:44 (00:0d:88:9b:09:44)
Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 62.146.25.34 (62.146.25.34)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 40
Identification: 0x02a4 (676)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 128
Protocol: TCP (0x06)
Header checksum: 0xde6a [correct]
Source: 192.168.1.101 (192.168.1.101)
Destination: 62.146.25.34 (62.146.25.34)
Transmission Control Protocol, Src Port: 1083 (1083), Dst Port: http (80), Seq: 1, Ack: 1, Len: 0
Source port: 1083 (1083)
Destination port: http (80)
Sequence number: 1 (relative sequence number)
Acknowledgement number: 1 (relative ack number)
Header length: 20 bytes
Flags: 0x0010 (ACK)
Window size: 65535
Checksum: 0x19dc [incorrect, should be 0xa2c5]
No. Time Source Destination Protocol Info
4 0.020746 192.168.1.101 62.146.25.34 HTTP GET / HTTP/1.1
Frame 4 (476 bytes on wire, 476 bytes captured)
Ethernet II, Src: FujitsuS_81:79:ea (00:30:05:81:79:ea), Dst: D-Link_9b:09:44 (00:0d:88:9b:09:44)
Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 62.146.25.34 (62.146.25.34)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 462
Identification: 0x02a5 (677)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 128
Protocol: TCP (0x06)
Header checksum: 0xdcc3 [correct]
Source: 192.168.1.101 (192.168.1.101)
Destination: 62.146.25.34 (62.146.25.34)
Transmission Control Protocol, Src Port: 1083 (1083), Dst Port: http (80), Seq: 1, Ack: 1, Len: 422
Source port: 1083 (1083)
Destination port: http (80)
Sequence number: 1 (relative sequence number)
Next sequence number: 423 (relative sequence number)
Acknowledgement number: 1 (relative ack number)
Header length: 20 bytes
Flags: 0x0018 (PSH, ACK)
Window size: 65535
Checksum: 0x1b82 [incorrect, should be 0xb2be]
Hypertext Transfer Protocol
No. Time Source Destination Protocol Info
5 0.071290 62.146.25.34 192.168.1.101 TCP http > 1083 [ACK] Seq=1 Ack=423 Win=49368 Len=0
Frame 5 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: D-Link_9b:09:44 (00:0d:88:9b:09:44), Dst: FujitsuS_81:79:ea (00:30:05:81:79:ea)
Internet Protocol, Src: 62.146.25.34 (62.146.25.34), Dst: 192.168.1.101 (192.168.1.101)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 40
Identification: 0x006c (108)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 50
Protocol: TCP (0x06)
Header checksum: 0x2ea3 [correct]
Source: 62.146.25.34 (62.146.25.34)
Destination: 192.168.1.101 (192.168.1.101)
Transmission Control Protocol, Src Port: http (80), Dst Port: 1083 (1083), Seq: 1, Ack: 423, Len: 0
Source port: http (80)
Destination port: 1083 (1083)
Sequence number: 1 (relative sequence number)
Acknowledgement number: 423 (relative ack number)
Header length: 20 bytes
Flags: 0x0010 (ACK)
Window size: 49368
Checksum: 0xe046 [correct]
No. Time Source Destination Protocol Info
6 0.075838 62.146.25.34 192.168.1.101 HTTP HTTP/1.1 200 OK (text/html)
Frame 6 (413 bytes on wire, 413 bytes captured)
Ethernet II, Src: D-Link_9b:09:44 (00:0d:88:9b:09:44), Dst: FujitsuS_81:79:ea (00:30:05:81:79:ea)
Internet Protocol, Src: 62.146.25.34 (62.146.25.34), Dst: 192.168.1.101 (192.168.1.101)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 399
Identification: 0x006d (109)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 50
Protocol: TCP (0x06)
Header checksum: 0x2d3b [correct]
Source: 62.146.25.34 (62.146.25.34)
Destination: 192.168.1.101 (192.168.1.101)
Transmission Control Protocol, Src Port: http (80), Dst Port: 1083 (1083), Seq: 1, Ack: 423, Len: 359
Source port: http (80)
Destination port: 1083 (1083)
Sequence number: 1 (relative sequence number)
Next sequence number: 360 (relative sequence number)
Acknowledgement number: 423 (relative ack number)
Header length: 20 bytes
Flags: 0x0018 (PSH, ACK)
Window size: 49368
Checksum: 0x29b8 [correct]
Hypertext Transfer Protocol
Line-based text data: text/html
No. Time Source Destination Protocol Info
7 0.095473 192.168.1.101 62.146.25.34 HTTP GET /favicon.ico HTTP/1.1
Frame 7 (407 bytes on wire, 407 bytes captured)
Ethernet II, Src: FujitsuS_81:79:ea (00:30:05:81:79:ea), Dst: D-Link_9b:09:44 (00:0d:88:9b:09:44)
Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 62.146.25.34 (62.146.25.34)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 393
Identification: 0x02aa (682)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 128
Protocol: TCP (0x06)
Header checksum: 0xdd03 [correct]
Source: 192.168.1.101 (192.168.1.101)
Destination: 62.146.25.34 (62.146.25.34)
Transmission Control Protocol, Src Port: 1083 (1083), Dst Port: http (80), Seq: 423, Ack: 360, Len: 353
Source port: 1083 (1083)
Destination port: http (80)
Sequence number: 423 (relative sequence number)
Next sequence number: 776 (relative sequence number)
Acknowledgement number: 360 (relative ack number)
Header length: 20 bytes
Flags: 0x0018 (PSH, ACK)
Window size: 65176
Checksum: 0x1b3d [incorrect, should be 0x1e0c]
Hypertext Transfer Protocol
No. Time Source Destination Protocol Info
8 0.139786 62.146.25.34 192.168.1.101 TCP http > 1083 [ACK] Seq=360 Ack=776 Win=49368 Len=0
Frame 8 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: D-Link_9b:09:44 (00:0d:88:9b:09:44), Dst: FujitsuS_81:79:ea (00:30:05:81:79:ea)
Internet Protocol, Src: 62.146.25.34 (62.146.25.34), Dst: 192.168.1.101 (192.168.1.101)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 40
Identification: 0x006e (110)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 50
Protocol: TCP (0x06)
Header checksum: 0x2ea1 [correct]
Source: 62.146.25.34 (62.146.25.34)
Destination: 192.168.1.101 (192.168.1.101)
Transmission Control Protocol, Src Port: http (80), Dst Port: 1083 (1083), Seq: 360, Ack: 776, Len: 0
Source port: http (80)
Destination port: 1083 (1083)
Sequence number: 360 (relative sequence number)
Acknowledgement number: 776 (relative ack number)
Header length: 20 bytes
Flags: 0x0010 (ACK)
Window size: 49368
Checksum: 0xdd7e [correct]
No. Time Source Destination Protocol Info
9 0.144850 62.146.25.34 192.168.1.101 HTTP HTTP/1.1 404 Not Found (text/html)
Frame 9 (464 bytes on wire, 464 bytes captured)
Ethernet II, Src: D-Link_9b:09:44 (00:0d:88:9b:09:44), Dst: FujitsuS_81:79:ea (00:30:05:81:79:ea)
Internet Protocol, Src: 62.146.25.34 (62.146.25.34), Dst: 192.168.1.101 (192.168.1.101)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 450
Identification: 0x006f (111)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 50
Protocol: TCP (0x06)
Header checksum: 0x2d06 [correct]
Source: 62.146.25.34 (62.146.25.34)
Destination: 192.168.1.101 (192.168.1.101)
Transmission Control Protocol, Src Port: http (80), Dst Port: 1083 (1083), Seq: 360, Ack: 776, Len: 410
Source port: http (80)
Destination port: 1083 (1083)
Sequence number: 360 (relative sequence number)
Next sequence number: 770 (relative sequence number)
Acknowledgement number: 776 (relative ack number)
Header length: 20 bytes
Flags: 0x0018 (PSH, ACK)
Window size: 49368
Checksum: 0x7a71 [correct]
Hypertext Transfer Protocol
Line-based text data: text/html
No. Time Source Destination Protocol Info
10 0.269307 192.168.1.101 62.146.25.34 TCP 1083 > http [ACK] Seq=776 Ack=770 Win=64766 [TCP CHECKSUM INCORRECT] Len=0
Frame 10 (54 bytes on wire, 54 bytes captured)
Ethernet II, Src: FujitsuS_81:79:ea (00:30:05:81:79:ea), Dst: D-Link_9b:09:44 (00:0d:88:9b:09:44)
Internet Protocol, Src: 192.168.1.101 (192.168.1.101), Dst: 62.146.25.34 (62.146.25.34)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 40
Identification: 0x02af (687)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 128
Protocol: TCP (0x06)
Header checksum: 0xde5f [correct]
Source: 192.168.1.101 (192.168.1.101)
Destination: 62.146.25.34 (62.146.25.34)
Transmission Control Protocol, Src Port: 1083 (1083), Dst Port: http (80), Seq: 776, Ack: 770, Len: 0
Source port: 1083 (1083)
Destination port: http (80)
Sequence number: 776 (relative sequence number)
Acknowledgement number: 770 (relative ack number)
Header length: 20 bytes
Flags: 0x0010 (ACK)
Window size: 64766
Checksum: 0x19dc [incorrect, should be 0x9fbe]lev wrote:This performance regression renders openvpn with a tun adapter unusable if client and server use kernel 3.14 .
Thus I created a bug report: https://bugs.archlinux.org/task/40089
i actually noticed it to be an "either-or" type of thing; my Windows clients were seeing the same thing coming off a 3.14 openvpn server.
yeah, weird issue. like i noticed spurts of even-powers-of-2 sized packets
Client connecting to 10.10.10.6, TCP port 5001
TCP window size: 416 KByte
[ 3] local 10.10.10.1 port 40643 connected with 10.10.10.6 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0- 2.0 sec 512 KBytes 2.10 Mbits/sec
[ 3] 2.0- 4.0 sec 0.00 Bytes 0.00 bits/sec
[ 3] 4.0- 6.0 sec 0.00 Bytes 0.00 bits/sec
[ 3] 6.0- 8.0 sec 0.00 Bytes 0.00 bits/sec
[ 3] 8.0-10.0 sec 128 KBytes 524 Kbits/sec
[ 3] 10.0-12.0 sec 128 KBytes 524 Kbits/sec
[ 3] 12.0-14.0 sec 512 KBytes 2.10 Mbits/sec
[ 3] 14.0-16.0 sec 128 KBytes 524 Kbits/sec
[ 3] 16.0-18.0 sec 512 KBytes 2.10 Mbits/sec
[ 3] 18.0-20.0 sec 128 KBytes 524 Kbits/sec
[ 3] 20.0-22.0 sec 384 KBytes 1.57 Mbits/sec
[ 3] 22.0-24.0 sec 256 KBytes 1.05 Mbits/sec
[ 3] 24.0-26.0 sec 512 KBytes 2.10 Mbits/sec
[ 3] 26.0-28.0 sec 384 KBytes 1.57 Mbits/sec
[ 3] 28.0-30.0 sec 256 KBytes 1.05 Mbits/sec
[ 3] 30.0-32.0 sec 128 KBytes 524 Kbits/sec
[ 3] 32.0-34.0 sec 640 KBytes 2.62 Mbits/sec
[ 3] 34.0-36.0 sec 384 KBytes 1.57 Mbits/sec
[ 3] 36.0-38.0 sec 384 KBytes 1.57 Mbits/sec
[ 3] 38.0-40.0 sec 384 KBytes 1.57 Mbits/sec
[ 3] 40.0-42.0 sec 128 KBytes 524 Kbits/sec -
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. -
Resolving a TCP connection "slowdown" problem
SuSE 9.3, stock kernel
Intel architecture
Jrockit-R26.4.0-jdk1.5.0_06-linux-ia32
I have a problem that appears to be localized in Jrockit (or
localized in the application, which is localized in Jrockit), where a
persistent and high-volume TCP connection slows down over the course
of about an hour--and eventually, effectively halts.
The TCP traffic is a stream of data, arriving at a near-constant rate
of about 16K bytes per second, with the receiving end (with the JVM
and app) strictly sending TCP ACKs in reply.
Restarting the sending process, or shutting down and restarting the
connection with the JVM / app, both restore the connection to full
speed until, over the course of perhaps an hour (sometimes more,
sometimes less) the same symptoms appear.
The symptoms in network packet traces are that when the connection is
first opened, the sender transmits packets at the full MTU of the
Ethernet segment. Gradually, the number of full-MTU sized packets
are replaced with packets much smaller packets, until most packets
range from 1 to 4 bytes with the occasional 3xx-4xx byte packet and
the odd offlier of a full-MTU packet size.
Supporting symptoms of interest:
1) The TCP window does not shrink
2) The CPU on the JVM/app side tops out at around 20%, even with
mySQL running on the machine
3) The interval between successive ACKs transmitted from the JVM/app
size generally narrows over the course of the connection
4) TCP send queue on the sender becomes saturated (pegged at 90+ K)
5) TCP receive queue on the JVM/app side is almost always 0, and when
it is not zero is bursts up to a low number (<50) and then almost
immediately returns to 0
6) The app does not appear to present any general symptoms of
slowness; the rate of writes to the database does not appear to slow.
The writes are threaded and multiplexed
[4] strongly implies that the slowness is caused by the JVM/app side,
since if the sender app was slowing down for some reason its TCP send
queue would not be saturated.
I can copiously document everything stated, and additionally provide
much additional detail.
Any guidance on how to suss out role Jrockit or the app are playing
in this little drama would be very deeply appreciated.Asked around and it seems unlikely that this is a JVM issue. We have never heard of this behavior before, and the network layer in the JVM doesn't do anything with MTU iirc with the possible exception of manual changes to socket options. It seems more likely that this is caused by the IP stack, the NIC device driver or something in the network configuration. Try making some changes here and see what happens. For instance:
1) Run client and server on the same machine, communicating through loopback
2) Try another Linux distro (CentOS 4.3, for instance)
3) Try a different NIC and/or a different device driver
In your Java code, check that you are closing all Socket objects properly. Leaving them to be closed by a finalizer can delay closing sockets resulting in a native resource leak. I don't see how that would cause the issue you describe, but you never know... -
Tuning Oracle*Net over TCP/IP
Hi,
Anyone have any info on how Oracle uses the SDU parameter in tnsnames.ora and listener.ora. Is the SDU in any way related to the maximum TCP data that the TCP socket between the client and server can have outstanding?
Does any one have experience with making oracle use the full tcp window (eg window > 32KB) between the Server and the client such as sqlplus?
Thanks,
SatyaHere is a useful article:
http://www.akadia.com/services/ora_net_tuning.html
SCJP, SCJD, SCEA, SCWCD, SCBCD
CISSP, PMP, PHR
OCPDBA 8i/9i
http://www.certgear.com
Maybe you are looking for
-
How do you check Memory Speed on ICD
Hi everyone I am new to the forums and I am also a soon to be first time mac owner(Receiving my 20" ICD this week) . I am buying the imac with an extra 1gig DIMM installed, non-apple memory. Now the reseller assures me that the 3rd party memory that
-
T61P Audio stuttering at bootup in Windows Vista Business
I did some googling on this and saw that mine isn't the only Lenovo with this issue, and it's not a big deal, but I would like to fix it so the bootup is silent until "music" (especially since I'm a musician with keen hearing and want my audio right)
-
I am having troubles aligning the label of my form to center. When the page loads, it looks like it wants to be center aligned, but then aligns to the left. I can't tell which CSS is making it do this. Would you be able to help me narrow it down? lin
-
I don't want to use my Apple ID I want to use a number
-
Has anyone migrated a 300gb or larger database to OATM? Are there any known performance issues after the database has been migrated to OATM?