1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Communication Error 8409 7175 When On A Wan Using Open Client

Discussion in 'Development' started by Clueless, Jul 21, 2017.

  1. Clueless

    Clueless New Member

    I have a C# program using an open client connection directly to a CentOs 6.5 Linux OpenEdge 10.2B patch 8 appserver -> database (does not use the nameserver).

    All works well when on a LAN.

    But when the Linux server was moved from a LAN to out-of-state data center, then started getting intermittent "Communication Error. Contact your system administrator. Communication layer message: Client Communication Failure - Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host. (8409) . (7175)."

    Data center has 20 MB upload/download network bandwidth as well as the client PC's office network.

    Looked at KBase 000035944 and it recommended adding the following file in the executable directory (the application is named surveyor.exe, so created a file named surveyor.exe.config)

    KBase 000035944 excerpt:

    To manually disable the socket time please use one of the following methods:
    • In the .NET application set the undocumented property Progress.Open4GL.RunTimeProperties.SocketTimeout to 0 before the connection is established.
    • In the application configuration file (e.g. app.config) set the socket timeout to 0. For example:

    <?xml version="1.0" encoding="utf-8" ?>
    <add key="PROGRESS.Session.SocketTimeout" value="0" />


    But this did not help.

    To test, when we add SSL capability to the C# client and appserver, then the communications error occurrences double.

    Also moved the database to the Amazon Cloud and got the same communication error.

    Called up Progress Tech Support but have not gotten a solution, either...

    Thanks in advance for any help.

  3. Clueless

    Clueless New Member


    I posted this in the Developer's Forum also, because I thought it could be solved by that Forum group as well as this one.

    I am just desperate to get an answer to this and I know that I cannot be the only person who has ever seen this problem...

  4. Tony Prettyman

    Tony Prettyman New Member

    Did you have any luck? Running into same issues here. Couldn't find your thread in Developer's Forum. Could you paste a link?
  5. Rob Fitzpatrick

    Rob Fitzpatrick ProgressTalk.com Sponsor

    Knowledge Article

    It may be your firewall or some other network device between the endpoints that is shutting down the connection.
  6. Clueless

    Clueless New Member

    Thanks for your response Rob.

    I have tried the PC client from the office and from home and get the same results. I have changed the office default gateway from a SonicWall firewall to a plain Linksys NAT router that has no advanced capabilities. Basically the same intermittent errors.

    I get the same error from the database located in the data center and also from the identical database located on the AWS instance. I fully control the AWS instance and to simplify networking to the max, it is running in AWS Classic mode, not even on a VPC. The only thing resembling a firewall is the standard AWS Security group, which I also temporarily opened full access on ALL ports. Same thing - intermittent errors.

    PC client <-> Simple NAT Router <-> AWS Classic Centos Instance with no software firewall enabled (iptables disabled)

    On the Windows PC on a commandline, ran a continuous ping to the server and did not have significant packet loss and no packet loss when the communication errors occurred.

    On the CentOs database server, ran netcat listening on port 3390 and in a PC commandline Window, ran telnet <IP address of the server> 3390
    There was no disconnection in that connection at all during a communications error: you could type characters on the PC keyboard and see them echo'd at the netcat screen stdout.

    I am going to get Wireshark running on both the PC client and the Centos database server to see if I can find the answer...

    ***Cringer, if you won't let me post this in the Developers Forum in addition to this one, can you _please_ move this thread to the Developers Forum? I really would like to have it posted in both, but if I have to select one or the other, I need to move to the other Developer forum where a different set of eyes might have the answer.

  7. TomBascom

    TomBascom Curmudgeon

    This sounds an awful lot like your C# socket handling code is the source of the problem.
  8. Cringer

    Cringer ProgressTalk.com Moderator Staff Member

    To be perfectly honest, the people that read here also read in development. If you're not getting the answer you want here, then I would suggest posting somewhere where more people are actually active. Nothing against ProgressTalk - it's a good resource, but often Progress Communities is a better place because Progress employees tend to actively read it, whereas they are less likely to read it here. Just my 2p.

    With Mod hat back on, I'm not 100% sure where this is best served. It's not really a development issue, but it's not really a dba one either.
  9. TomBascom

    TomBascom Curmudgeon

    IMHO it is more a dev issue than a DBA issue.
  10. Cringer

    Cringer ProgressTalk.com Moderator Staff Member

    I stand by your opinion then, Tom. Moved :)

Share This Page