Simens TCP/IP stack

Hi,
I worked all the day to watch TCP packets traveling between my J2ME client (GPRS connection) and my J2EE server (Internet connection).
I used WireShark (ex Ethereal) to sniff the network.
I could see through this sniffer that sometimes, my client TCP connection are not terminated (FIN flag). After, another connection (SYN flag) is established and everything is fine...and maybe after it will appear again...
In addition, sometimes (again), my client write on its socket outputstream and I can't see the TCP packet on my sniffer (so my server is waiting until a timeout occurs)...
(see my last post... http://forum.java.sun.com/thread.jspa?threadID=5261959)
I work on a Siemens TC65. Globally, do you guys saw some weird stuff like this with mobile TCP stack ? I mean is there something to know about TCP protocol with mobile phone?
I'm really pissed about this I don't know if I made a mistake or if GPRS connection is not reliable with TCP!
Thanks...

AdrienD wrote:
SIEMENS
TC65
REVISION 02.800I never heard of this one... We are still working with the 2.000 releases and we are getting prereleases of the rev 3 modules soon. Is this one of those maybee? If so, you might try a rev 2.000 module..
What is your client, and what is your server, and where are they located?My server is in my private network. I added a NAT on my router to link every TCP connection on port 9000 to my server private ip address. That's called port forwarding.
My client is connected through GPRS on its local mobile network to my ISP router (I guess).
When I see a TCP packet coming from my client, source IP address is an Internet IP so I think it is my ISP public IP address ....
My server...<-------------------> My router (with NAT on TCP port 9000) <------------INTERNET------------> ISP Router <----------------------> My clientYes, usually, the GPRS network is a NAT'ed network, meaning that every unit will present itself with the same IP to the server. The ISP NAT router manages TCP connections and therefore knows where it should the TCP packets to. This way, you can't directly connect to any of the GPRS units.
Other ISP might actually give every GPRS unit a real internet IP, making it possible to connect to the units directly. We have our own APN, and the units get an IP directly form out own authentication server and reside in our own network via a VPN connection. This way we have all the freedom we need.

Similar Messages

TCP/IP stack

Dear All,
I want to know TCP/IP stack, can anyone help me by providing TCP/IP stack chart.
Jitesh

Hi,
This is also a very helpfull link:
http://en.wikipedia.org/wiki/Internet_protocol_suite
If you find this post usefull
please don't forget to rate this
#Iwan Hoogendoorn

How to reconfigure the tcp/ip stack in Solar8 to include my STREAMS module?

I am currently writing a NAT STREAMS module that I would like to place on the tcp/ip stack so it intercepts all incoming and outgoing packets going to or coming from the IP module. I want the stack to look like the following:
Current Solaris Stack: hme0 -> ip -> tcp
The new stack I want: hme0 -> MY_NAT -> ip -> tcp
I would appreciate any help to my problem. Also, if anyone knows a resource where I could find any more information like this please let me know. I've look at docs.sun.com and searched the web but I still haven't found the answer.
Thanks,
Ben

Check out the Solaris 8 (or 9) STREAMS programming manual on docs.sun.com.
It covers in detail how from userspace or from kernelspace linking a STREAMS module into the chain of modules. I think the example it gives is with terminal drivers, but same idea.

Windows TCP/IP stack and packet bursts

Hi all!
I'm trying to make a server that sends ~30 packets (tcp/ip) loaded with a little data (a long). (Streaming with dataOutputStream.writeLong())
I would really like to get those 30 Hz signals updating on the clients in a smooth fashion.
On linux/mac (on those I have tested), I receive the packets one by one. But, in Windows, I receive them as bursts 5/pause/5/pause... and so on. This is really annoying. Anyone knows what the problem might be? I suspect some tcp/ip stack in windows...
I have heard ppl streaming with 100Hz, so this might not be a problem? Or should I use UDP datagram packets instead?
Thank you!

First, there is no 'problem', as none of the RFCs guarantees the kind of behaviour that you want, so you may be better off reviewing your requirement for feasibility rather than chasing some non-existent 'problem'.
Having said that, there are all kinds of TCP/IP parameters you can tune via the Windows registry:
http://technet2.microsoft.com/WindowsServer/en/Library/823ca085-8b46-4870-a83e-8032637a87c81033.mspx

Issue Exporting TCP IP stack information to CSV file

I'm having difficulties reporting IP information (IPAddress, Default Gateway,
and DNSSearchOrder) in TCP IP stack and exporting it to CSV file. But if I remove the export-CSV statement everything appears fiine on the screen. for privacy reasons I've removed columns after DNS Search Order. note my examples below:
Get-WMIObject -Class Win32_NetworkAdapterConfiguration -ComputerName (Get-Content .\Servers.txt) -Credential DOMAIN\USERADDCOUNT |
Where-Object -FilterScript {$_.IPEnabled} |
    Select-Object DNSHostName, IPAddress, DefaultIPGateway, DNSServerSearchOrder, WINSPrimaryServer, WINSSecondaryServer,
@ {Label="ADSDomainName";Expression={(Get-WMIObject -Class Win32_ComputerSystem -ComputerName $_.__Server).Domain}} |
     Export-csv PowerShell-ServerProfileIPInformation.csv -NoTypeInformation
DNSHostName    IPAddress       DefaultIPGateway DNSServerSearchOrder
SERVER1100496 System.String[] System.String[]    System.String[]
SERVER1100497 System.String[] System.String[]    System.String[]
SERVER1100169 System.String[] System.String[]    System.String[]
SERVER1100496 System.String[] System.String[]    System.String[]
SERVER1100497 System.String[] System.String[]    System.String[]
SERVER1100169 System.String[] System.String[]    System.String[]
SERVER1100496 System.String[] System.String[]    System.String[]
SERVER1100497 System.String[] System.String[]    System.String[]
SERVER1100169 System.String[] System.String[]    System.String[]

Hi,
This is happening because you are trying to export a array. Simple way to get rid of this is, convert the array into comma separated values and then export it.I slightly modified your code as below.
$IPs = Get-WMIObject -Class Win32_NetworkAdapterConfiguration -ComputerName (Get-Content .\Servers.txt) -Credential DOMAIN\USERADDCOUNT | ? {$_.IPEnabled }
$Outarray = @()
foreach($IP in $IPs) {
$OutputObj = New-Object -TypeName PSobject
$OutputObj | Add-Member -MemberType NoteProperty -Name ComputerName -Value $IP.DNSHostName
$OutputObj | Add-Member -MemberType NoteProperty -Name IPAddress -Value $IP.IPAddress -join ","
$OutputObj | Add-Member -MemberType NoteProperty -Name DefaultIPGateway -Value $IP.DefaultIPGateway -join ","
$Outarray += $OutputObj
$OutArray | export-csv c:\temp\IPdetails.csv -NoTypeInformation
If you want to understand more on how to export such kind of data to csv/excel, refer to this(http://learn-powershell.net/2014/01/24/avoiding-system-object-or-similar-output-when-using-export-csv/) article written by Boe Prox. It is really worth reading.
If you are looking for complete script that can export Ip config details of remote computers into CSV, try the script mentioned at
http://techibee.com/powershell/powershell-get-ip-address-subnet-gateway-dns-serves-and-mac-address-details-of-remote-computer/1367
Hope this helps.
Thanks,
Sitaram Pamarthi
Blog : http://techibee.com
Follow on Twitter
This posting is provided AS IS with no warranties or gurentees,and confers no rights

Server 2008 (R2) TCP/IP Stack sending RST to close short lived sessions

Hi,
I'm having an issue with some vendor software, but it appears to be more closely related to the way the TCP/IP stack is handling session shutdown. I'd like to know what this feature is called, any available documentation, and ideally how to disable it.
Basically, what appears to happen, is Server 2008 is sending a Rst, Ack to terminate a short lived connection, instead of entering the standard TCP shutdown (Using FIN flags). This appears to be an attempt to avoid having short lived sessions sit in a
TIME_WAIT state, as I can see long TCP connections properly being shutdown.
I realize the benefits of what this is trying to accomplish, however, the software in question is making HTTP calls, and the server being rather basic, is sending HTTP responses without content-length or transfer encoding: chunked, which means the only
way to tell the server is done sending content is for the connection to close. However, it appears that the stack is interpreting this type of Tcp shutdown as in error, and generating annoying alerts within the application that is monitoring the close state.
Does windows have a way to disable this stack feature. I've confirmed the chimney offload doesn't appear to be in use, so this is an effect of the Windows stack itself. I don't have control of the software on either end, but do have a bug open with the vendor,
I'm more interested in a possible workaround for the short term.
** Entire connection lasts ~1 second
Internet Protocol, Src: 172.25.149.231 (172.25.149.231), Dst: 172.25.147.172 (172.25.147.172)
Transmission Control Protocol, Src Port: 49740 (49740), Dst Port: 8089 (8089), Seq: 0, Len: 0
Flags: 0x02 (SYN)
Internet Protocol, Src: 172.25.147.172 (172.25.147.172), Dst: 172.25.149.231 (172.25.149.231)
Transmission Control Protocol, Src Port: 8089 (8089), Dst Port: 49740 (49740), Seq: 0, Ack: 1, Len: 0
Flags: 0x12 (SYN, ACK)
Internet Protocol, Src: 172.25.149.231 (172.25.149.231), Dst: 172.25.147.172 (172.25.147.172)
Transmission Control Protocol, Src Port: 49740 (49740), Dst Port: 8089 (8089), Seq: 1, Ack: 1, Len: 0
Flags: 0x10 (ACK)
Internet Protocol, Src: 172.25.147.172 (172.25.147.172), Dst: 172.25.149.231 (172.25.149.231)
Transmission Control Protocol, Src Port: 8089 (8089), Dst Port: 49740 (49740), Seq: 1, Ack: 2921, Len: 0
Flags: 0x10 (ACK)
Internet Protocol, Src: 172.25.149.231 (172.25.149.231), Dst: 172.25.147.172 (172.25.147.172)
Transmission Control Protocol, Src Port: 49740 (49740), Dst Port: 8089 (8089), Seq: 2921, Ack: 1, Len: 1234
Flags: 0x18 (PSH, ACK)
Internet Protocol, Src: 172.25.147.172 (172.25.147.172), Dst: 172.25.149.231 (172.25.149.231)
Transmission Control Protocol, Src Port: 8089 (8089), Dst Port: 49740 (49740), Seq: 1, Ack: 4155, Len: 57
Flags: 0x18 (PSH, ACK)
Internet Protocol, Src: 172.25.149.231 (172.25.149.231), Dst: 172.25.147.172 (172.25.147.172)
Transmission Control Protocol, Src Port: 49740 (49740), Dst Port: 8089 (8089), Seq: 4155, Ack: 58, Len: 0
Flags: 0x10 (ACK)
Internet Protocol, Src: 172.25.147.172 (172.25.147.172), Dst: 172.25.149.231 (172.25.149.231)
Transmission Control Protocol, Src Port: 8089 (8089), Dst Port: 49740 (49740), Seq: 58, Ack: 4155, Len: 1024
Flags: 0x18 (PSH, ACK)
Internet Protocol, Src: 172.25.147.172 (172.25.147.172), Dst: 172.25.149.231 (172.25.149.231)
Transmission Control Protocol, Src Port: 8089 (8089), Dst Port: 49740 (49740), Seq: 1082, Ack: 4155, Len: 1460
Flags: 0x18 (PSH, ACK)
Internet Protocol, Src: 172.25.149.231 (172.25.149.231), Dst: 172.25.147.172 (172.25.147.172)
Transmission Control Protocol, Src Port: 49740 (49740), Dst Port: 8089 (8089), Seq: 4155, Ack: 2542, Len: 0
Flags: 0x10 (ACK)
Internet Protocol, Src: 172.25.147.172 (172.25.147.172), Dst: 172.25.149.231 (172.25.149.231)
Transmission Control Protocol, Src Port: 8089 (8089), Dst Port: 49740 (49740), Seq: 2542, Ack: 4155, Len: 1460
Flags: 0x18 (PSH, ACK)
Internet Protocol, Src: 172.25.147.172 (172.25.147.172), Dst: 172.25.149.231 (172.25.149.231)
Transmission Control Protocol, Src Port: 8089 (8089), Dst Port: 49740 (49740), Seq: 4002, Ack: 4155, Len: 1460
Flags: 0x18 (PSH, ACK)
Internet Protocol, Src: 172.25.147.172 (172.25.147.172), Dst: 172.25.149.231 (172.25.149.231)
Transmission Control Protocol, Src Port: 8089 (8089), Dst Port: 49740 (49740), Seq: 5462, Ack: 4155, Len: 1460
Flags: 0x18 (PSH, ACK)
Internet Protocol, Src: 172.25.147.172 (172.25.147.172), Dst: 172.25.149.231 (172.25.149.231)
Transmission Control Protocol, Src Port: 8089 (8089), Dst Port: 49740 (49740), Seq: 6922, Ack: 4155, Len: 1081
Flags: 0x18 (PSH, ACK)
Internet Protocol, Src: 172.25.149.231 (172.25.149.231), Dst: 172.25.147.172 (172.25.147.172)
Transmission Control Protocol, Src Port: 49740 (49740), Dst Port: 8089 (8089), Seq: 4155, Ack: 8003, Len: 0
Flags: 0x10 (ACK)
Internet Protocol, Src: 172.25.147.172 (172.25.147.172), Dst: 172.25.149.231 (172.25.149.231)
Transmission Control Protocol, Src Port: 8089 (8089), Dst Port: 49740 (49740), Seq: 8003, Ack: 4155, Len: 1460
Flags: 0x18 (PSH, ACK)
Internet Protocol, Src: 172.25.147.172 (172.25.147.172), Dst: 172.25.149.231 (172.25.149.231)
Transmission Control Protocol, Src Port: 8089 (8089), Dst Port: 49740 (49740), Seq: 9463, Ack: 4155, Len: 108
Flags: 0x18 (PSH, ACK)
Internet Protocol, Src: 172.25.149.231 (172.25.149.231), Dst: 172.25.147.172 (172.25.147.172)
Transmission Control Protocol, Src Port: 49740 (49740), Dst Port: 8089 (8089), Seq: 4155, Ack: 9571, Len: 0
Flags: 0x10 (ACK)
Internet Protocol, Src: 172.25.147.172 (172.25.147.172), Dst: 172.25.149.231 (172.25.149.231)
Transmission Control Protocol, Src Port: 8089 (8089), Dst Port: 49740 (49740), Seq: 9571, Ack: 4155, Len: 0
Flags: 0x14 (RST, ACK)

Rick, this did not help as it's the approach i've already taken in testing. Albeit, I did disable the chimney offload on the NIC drivers instead of the windows options, but in the wireshark captures I'm still seeing the same behavior.
Humand, I don't think you're issue is the same as mine, I beleive these RST, ACK's are in response to a NORMAL connection shutdown, and being interpretted as errors be the partner stack. I haven't seen this cause premature tcp shutdown, which would be you're
dropped RDP connections.
TCP Global Parameters
Receive-Side Scaling State : disabled
Chimney Offload State : disabled
NetDMA State : enabled
Direct Cache Acess (DCA) : disabled
Receive Window Auto-Tuning Level : disabled
Add-On Congestion Control Provider : ctcp
ECN Capability : disabled
RFC 1323 Timestamps : disabled

Tcp/ip stacks

I have been trying to set up my wireless network for a couple of days now. My router is a WRT54GS and the problem I am having is on my desktop with the wireless adapter. I can connect to the network and can ping the router with no problem. It is when I try to connect to the internet I keep getting the cannot find page error. Tech support says I need to check my tcp/ip stacks and my DNS address. Does anyone know how to refresh the tcp/ip stacks on Windows ME and how to resolve the DNS issue.
Thanks Jabe

pls visit this one... this will tell you how to refresh your TCP/IP stacking
http://support.microsoft.com/kb/299357
"a helping hand in a community makes the world a universe"

TCP/IP Stack Manipulation

In my mind, I can't think of a way to do this without going native but... maybe one of you have another outlook?
I'd like to redirect traffic on a certain IP range.

hi,
let say you have the main ServerSocket called 'gate' and one called 'redirected'. All clients connect to 'gate'. if the IP is allowed you process else use a class what would connect to 'redirected' and act like a proxy.

ASIP dumps TCP stack nightly

We have been running ASIP 6.3 since 2001, migrating it through several servers. For the past 8 months, it has resided on an early-edition G4 (ID 106, ROM 7.5.1) with 1.5GB RAM and two ATA drives supporting a small school (100 user accounts, rarely > 30 logged on at once). The server provides only AFS services, using both TCP/IP and AppleTalk. The underlying system is OS 9.1.1 (we found it would not install on 9.2). Until 3 weeks ago we'd never had a real problem we hadn't caused ourselves.
For the last 3 weeks, every morning when we arrive at school the server is hung, requiring a hard restart. There is usually (but not always) an error message: "TCP stack was dumped." We tried turning off TCP/IP service from Server Manager, but that didn't change the problem. This ONLY happens overnight -- otherwise, all services run smoothly. The machine is on a UPS which tests OK, and is set to restart if it loses power.
We can't tell if this is an ASIP error or an OS 9.1.1 error. We've never seen this error before (between us we have over 2 decades of Appleshare server management experience behind us).
Ideas?

Look at this site for getting 9.2.2 and 6.3.3 up on your Server:
http://os9forever.com
Click the link on the left labeled ASIP patch. Print out and read the documents. I tried to install the patch, and could not quite get it to work, but in reading the discussion and examining the files in question, I realized a drag-and-drop install of the crucial parts was all that was needed. It worked fine.
One possibility on dumping the TCP/IP stack may be lurking in the TCP/IP Control Panel. If the "load only when needed" box is checked, when things get very quiet, it may just unload it.
I am not certain whether that parameter is one of the several AppleTalk/ TCP parameters stored in Parameter RAM, but a PRAM reset at a minimum, and replacing the battery at the extreme may be in order anyway.

TCP connection error when sending MODBUS commands to WAGO 750-881 controller after 113655 bytes of data have been sent

Hi all,
I am new to the world of labview and am attempting to build a VI which sends commands to a 750-881 WAGO controller at periodic intervals of 10ms.
To set each of the DO's of the WAGO at once I therefore attempt to send the Modbus fc15 command every 10ms using the standard Labview TCP write module.
When I run the VI it works for about a minute before I recieve an Error 56 message telling me the TCP connection has timed out. Thinking this strange, I decided to record the number of bytes sent via the TCP connection whilst running the program. In doing so I noticed that the connection broke after exactly 113655 Bytes of data had been sent each time.
Thinking that I may have been sending too many messages I increased the While-loop delay from 10ms to 20, 100 and 200 ms but the error remained. I also tried playing with the TCP connection timeout and the TCP write timeout but neither of these had any effect on the problem.
I cannot see why this error is occuring, as the program works perfectly up untill the 113655 Bytes mark.
I have attached a screenshot of the basic VI (simply showing a MODBUS command being sent every second) and of a more advanced VI (where I am able to control each DO of the WAGO manually by setting a frequency at which the DO should switch between ON and OFF).
If anybody has any ideas on where the problems lie, or what I could do to further debug the program this would be greatly appreciated.
Solved!
Go to Solution.
Attachments:
Basic_VI.png ‏84 KB
Expanded_VI.png ‏89 KB

AvdLinden wrote:
Hi ThiCop,
Yes the error occurs after exactly 113655 bytes every time. The timeout control I would like to use is 10ms, however even increasing this to 1s or 10s does not remove the error, which leads me to believe that this is not the issue (furthermore, not adding any delay to the while loop, thus letting it run at maximum speed, has shown that the TCP connection is able to send all 113655 bytes in under 3 seconds again pointing towards the timeout control not being the issue here).
I attempted Marco's suggestion but an having difficulty translating the string returned into a readable string, (rightnow the response given is " -# + ").
As to your second suggestion, I implemented something similar where I created a sub VI to build a TCP connection, send a message and then close the connection. I now build each message and then send the string to this subVI which successfully sends the command to my application. Whilst not being the most elegant method of solving the issue, it has resolved the timeout problem meaning I am able to send as many commands as I want. So in that sense the problem has been solved.
If you still have tips on how to correctly read the TCP read output, I would however like to see if I could not get my first program to work as it is slightly more robust in terms of timing.
Modbus TCP RTU is a binary protocol, as you show in your Basic VI, where you format the data stream using byte values. So you have to interprete the returned answer accordingly with the Modbus RTU spec in hand. Now what is most likely happening is that the connection gets hung after a while since you do NOT read the data the device sends as response to your commands. The TCP/IP stack buffers those bytes and at some point the internal buffers overflow and the connection is blocked by the stack. So adding the TCP Read at strategic places (usually after each write) is the proper solution for this. Is there any reason that you didn't use the NI provided Modbus TCP library?
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

IPS Tech Tip - Evasions - TCP/IP examples and handling - Sig team presentation

Hi Customers,
Its summer time and nothing evokes cool quite like a discussion into the TCP / IP stack and how creative attacker types try to hide attacks behind it. This presentation will feature a security researcher from our signature team and will be the first of several presentations on evastions and how the Cisco IPS handle them.
We hope that you can make it.
Thanks,
-Robert
Robert Albach invites you to attend a 30-45 minute Web seminar on the Cisco IPS internal operations using WebEx. This event requires registration.
Topic: Cisco IPS Tech Tips - Handling Evasions
Host: Robert Albach
Date and Time:
August 25, 2011 9:30 am, Central Daylight Time (Chicago, GMT-05:00)
To register for the online event
1. Go to https://ciscosales.webex.com/ciscosales/onstage/g.php?d=201261254&t=a&EA=ralbach%40cisco.com&ET=64ed8e6d81005252203f6671cfeee480&ETR=fb46b8799a6afe989e9a744f0fac0d77&RT=MiM3&p
2. Click "Register".
3. On the registration form, enter your information and then click "Submit".
Once the host approves your registration, you will receive a confirmation email message with instructions on how to join the event.

Sadly we did not get the recording done. The presentation and the example pcaps however are on this forum now.
-Robert

Extend-TCP client not failing over to another proxy after machine failure

I have a configuration of three hosts. on A is the client, on B & C are a proxy and a cache instance. I've defined an AddressProvider that returns the address of B and then C. The client just repeatedly calls the cache (read-only). The client configuration is:
<?xml version="1.0"?>
<cache-config
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-cache-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-cache-config
coherence-cache-config.xsd">
<caching-scheme-mapping>
<cache-mapping>
<cache-name>cache1</cache-name>
<scheme-name>extend-near</scheme-name>
</cache-mapping>
</caching-scheme-mapping>

<caching-schemes>
<near-scheme>
<scheme-name>extend-near</scheme-name>
<front-scheme>
<local-scheme>
<high-units>1000</high-units>
</local-scheme>
</front-scheme>
<back-scheme>
<remote-cache-scheme>
<scheme-ref>remote-cache1</scheme-ref>
</remote-cache-scheme>
</back-scheme>
<invalidation-strategy>all</invalidation-strategy>
</near-scheme>
<remote-cache-scheme>
<scheme-name>remote-cache1</scheme-name>
<service-name>cache1ExtendedTcpProxyService</service-name>
<initiator-config>
<tcp-initiator>
<remote-addresses>
<address-provider>
<class-name>com.foo.clients.Cache1AddressProvider</class-name>
</address-provider>
</remote-addresses>
<connect-timeout>10s</connect-timeout>
</tcp-initiator>
<outgoing-message-handler>
<request-timeout>5s</request-timeout>
</outgoing-message-handler>
</initiator-config>
</remote-cache-scheme>
</caching-schemes>
If I shutdown the proxy that the client is connected to on host B, failover occurs quickly by calling the AddressProvider. But if I shut down the network for host B (or drop the TCP port of the proxy on B) to simulate a machine failure, failover does not occur. The client simply continues to try to contact B and dutifully times out in 5 seconds. It never asks the AddressProvider for another address.
How do I get failover to kick in?

Hello,
If you are testing Coherence*Extend failover in the face of a network, machine, or NIC failure, you should enable Connection heartbeats on both the <tcp-initiator/> and <tcp-acceptor/>. For example:
Client cache config:
<remote-cache-scheme>
<scheme-name>extend-direct</scheme-name>
<service-name>ExtendTcpCacheService</service-name>
<initiator-config>
    <tcp-initiator>
      <remote-addresses>
        <socket-address>
          <address system-property="tangosol.coherence.extend.address">localhost</address>
          <port system-property="tangosol.coherence.extend.port">9099</port>
        </socket-address>
      </remote-addresses>
      <connect-timeout>2s</connect-timeout>
    </tcp-initiator>
    <outgoing-message-handler>
      <heartbeat-interval>10s</heartbeat-interval>
      <heartbeat-timeout>5s</heartbeat-timeout>
      <request-timeout>15s</request-timeout>
    </outgoing-message-handler>
</initiator-config>
</remote-cache-scheme>Proxy cache config:
<proxy-scheme>
<scheme-name>example-proxy</scheme-name>
<service-name>ExtendTcpProxyService</service-name>
<thread-count system-property="tangosol.coherence.extend.threads">2</thread-count>
<acceptor-config>
    <tcp-acceptor>
      <local-address>
        <address system-property="tangosol.coherence.extend.address">localhost</address>
        <port system-property="tangosol.coherence.extend.port">9099</port>
      </local-address>
    </tcp-acceptor>
    <outgoing-message-handler>
      <heartbeat-interval>10s</heartbeat-interval>
      <heartbeat-timeout>5s</heartbeat-timeout>
      <request-timeout>15s</request-timeout>
    </outgoing-message-handler>
</acceptor-config>
<autostart system-property="tangosol.coherence.extend.enabled">true</autostart>
</proxy-scheme>This is because it may take the TCP/IP stack a considerable amount of time to detect that it's peer is unavailable after a network, machine, or NIC failure (O/S dependent).
Jason

JIMM and the TCP settings

Hello all,
On different sites in different threads I read that many people have problems getting the JIMM messenger software running because of the network settings. I am one of them. The problem is, that there are some hints which I all tried, but there is no real solution. Perhaps someone here can help.
The problem should be the same for any other software using direct internet connection.
What I already managed: It runs using sockets connection via the APN "web.vodafone.de", which I entered in Options - TCP.
Since I'm additionally charged for this APN I would like to have it work using the blackberry APN "blackberry.net". I entered it in the TCP settings.
So here are my questions:
1) Do I need login information for the APN "blackberry.net" (user / password)?
2) Does this APN only support HTTP or also sockets? Both does not work on my BB. I get errors 118 or 125.
3) I using HTTP, which are the correct settings for port, user agent and profile in the JIMM software? If you cannot enter the correct strings, please tell me where I can copy them. (Service books etc.?)
4) Are there any additional settings I have to change?
Thanks a lot in advance.
Joerg.

I doubt you can do something about this from within Java. The TCP/IP stack is not a part of Java. It is handled by the operating system. Sorry...
/Michael

Why tcp closed by peer when trying to read msg after the successful Listen?

Hi everyone,
I had trouble to read data after Listen function return a good connection ID. The embedded application is running in ARM processor and I build a PC application with Labview to read the device status via TCP connecion. There are required two TCP connections between embedded application and PC application with specific port to listen on each side. After exchange port number by UDP message, both sides know the destination port to send msg. I can send request to embedded apllication in one TCP connection then listen to other TCP connection for reply. By monitroing the traffic of network card, I can see the successful TCP open sequence and in coming reply data, but Labview application shows error 66 "network connection closed by peer" when trying to read data, which is quite strange. I already see those data with network monitor tool, such as wire shark.
Did anybody experience the similar problem? and provide some suggestion? Is it problem of configuration of Labview? windows XP? I am using Labview 6.1.
Thanks
Lei
Solved!
Go to Solution.

LeiJ wrote:
Thanks Mike,
The problem was solved. It is timing issue. There is another while loop in code which sends heartbeat UDP message regularly for ervry 10 seconds, and this cause the problem of TCP read function. If I stop or remove this thread of while loop, the read function works fine. The UDP heartbeat message is only need to use once at first beginning to broadcast port number when setup TCP connection. Possibly I can send the heartbeat somewhere esle. I think the TCP error code 56 (timeout) and 66 (network connection closed by peer) is not distinguished in TCP read function. Thank you for reply and suggestion.
Regards
Lei
Actually LabVIEW distinguish between these errors very specifically. If you get an error 66 the connection was closed for sure, either explicitedly by the peer of implicitedly by the TCP IP stack after loosing the connection for to long such as when the Ethernet card would be disabled.
The issue most likely is that your client after sending back an open-package expects a specific response in a specific amount of time and closes the connection down if it does not get a valid response. Seems like a good measure to try to minimize the resources on your embedded target that need to be allocated when a badly behaving client is looping in a connection attempt.
Rolf Kalbermatter
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

Windows 7 - TCP Parameter TcpMaxConnectRetransmissions and TcpInitialRTT

(this is a dummy post, for an issue which has been resolved under the partner area after i raised a break fix ticket with Microsoft, but not available to the wider audience)
We have a redundant NIC situation where we want the swap on failure to be fast, i.e. we want the default TcpMaxConnectRetransmissions to be 0 or 1, not 2. The resulting default no connection time is 21s
Research has shown posts like
http://go4answers.webhost4life.com/Example/window-registy-14268.aspx which implies this has been dropped in Windows 7 and you can no longer control a range of settings. Also see
http://blogs.technet.com/b/netro/archive/2010/08/30/tcp-ip-stack-hardening-in-operating-systems-starting-with-windows-vista.aspx
There is also TcpInitialRTT but neither work. However their is a KB
http://support.microsoft.com/kb/170359 which imply they should work. Someone is tell porkies ?
>> Is this true, we can't adjust the timeout for a connection in Windows 7, or is there still a backdoor to this functionality ?
Thanks

Hi,
I’m glad to hear your issue has been resolved. Hope your experience will help other community members facing similar problems.
Regards,
Leo
Huang
TechNet Subscriber Support
If you are
TechNet Subscription user and have any feedback on our support quality, please send your feedback
here.
Leo Huang
TechNet Community Support

Simens TCP/IP stack

Similar Messages

Maybe you are looking for