I have a running web service connection between a Java client program with the Metro {2.2.1-1} web service stack and a WCF {.NET 4.0 v30319} wsHttpBinding web service on Windows XP SP3.
If I move the exact same setup to a Windows 7 {with some enterprise setup} or Windows 2008 R2 Server SP1 {from MS DVD}, I get hanging requests from the Java client to the WCF service. I.e. there are no symptoms of any data exchange between the two partners {I have -Dcom.sun.xml.ws.transport.http.client.HttpTransportPipe.dump=true on the client side and diagnostic print messages on the server side -- both without output}. Networkologically, a TCP connection is open ("netstat -a") until a timeout occurs after 200+-5 seconds with the following stack trace:
Jul 19, 2013 12:13:00 PM ch.xxxxxxxx.xxxxx.balance.client.start.Start main
SEVERE: null
com.sun.xml.ws.streaming.XMLStreamReaderException: XML reader error: com.ctc.wstx.exc.WstxIOException: Connection reset
at com.sun.xml.ws.streaming.XMLStreamReaderUtil.wrapException(XMLStreamReaderUtil.java:326)
at com.sun.xml.ws.streaming.XMLStreamReaderUtil.next(XMLStreamReaderUtil.java:99)
at com.sun.xml.ws.streaming.XMLStreamReaderUtil.nextContent(XMLStreamReaderUtil.java:169)
at com.sun.xml.ws.streaming.XMLStreamReaderUtil.nextElementContent(XMLStreamReaderUtil.java:104)
at com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parseBinding(RuntimeWSDLParser.java:584)
at com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parseWSDL(RuntimeWSDLParser.java:470)
at com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parseImport(RuntimeWSDLParser.java:427)
at com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parseImport(RuntimeWSDLParser.java:835)
at com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parseWSDL(RuntimeWSDLParser.java:464)
at com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parse(RuntimeWSDLParser.java:232)
at com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parse(RuntimeWSDLParser.java:192)
at com.sun.xml.ws.wsdl.parser.RuntimeWSDLParser.parse(RuntimeWSDLParser.java:161)
at com.sun.xml.ws.client.WSServiceDelegate.parseWSDL(WSServiceDelegate.java:328)
at com.sun.xml.ws.client.WSServiceDelegate.<init>(WSServiceDelegate.java:290)
at com.sun.xml.ws.client.WSServiceDelegate.<init>(WSServiceDelegate.java:217)
at com.sun.xml.ws.client.WSServiceDelegate.<init>(WSServiceDelegate.java:199)
at com.sun.xml.ws.client.WSServiceDelegate.<init>(WSServiceDelegate.java:195)
at com.sun.xml.ws.spi.ProviderImpl.createServiceDelegate(ProviderImpl.java:112)
at javax.xml.ws.Service.<init>(Unknown Source)
at ch.xxxxxxxx.xxxxx.balance.client.SystemIntegrationServiceBridge.<init>(SystemIntegrationServiceBridge.java:50)
at ch.xxxxxxxx.xxxxx.balance.client.start.Start.main(Start.java:37)
Caused by: com.ctc.wstx.exc.WstxIOException: Connection reset
at com.ctc.wstx.sr.StreamScanner.constructFromIOE(StreamScanner.java:625)
at com.ctc.wstx.sr.StreamScanner.loadMoreFromCurrent(StreamScanner.java:1049)
at com.ctc.wstx.sr.StreamScanner.parseLocalName2(StreamScanner.java:1857)
at com.ctc.wstx.sr.StreamScanner.parseLocalName(StreamScanner.java:1817)
at com.ctc.wstx.sr.BasicStreamReader.handleStartElem(BasicStreamReader.java:2925)
at com.ctc.wstx.sr.BasicStreamReader.nextFromTree(BasicStreamReader.java:2817)
at com.ctc.wstx.sr.BasicStreamReader.next(BasicStreamReader.java:1065)
at com.sun.xml.ws.util.xml.XMLStreamReaderFilter.next(XMLStreamReaderFilter.java:96)
at com.sun.xml.ws.streaming.XMLStreamReaderUtil.next(XMLStreamReaderUtil.java:80)
... 19 more
Caused by: java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(Unknown Source)
at java.net.SocketInputStream.read(Unknown Source)
at java.io.BufferedInputStream.fill(Unknown Source)
at java.io.BufferedInputStream.read1(Unknown Source)
at java.io.BufferedInputStream.read(Unknown Source)
at sun.net.www.MeteredStream.read(Unknown Source)
at java.io.FilterInputStream.read(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection$HttpInputStream.read(Unknown Source)
at com.ctc.wstx.io.BaseReader.readBytes(BaseReader.java:155)
at com.ctc.wstx.io.UTF8Reader.loadMore(UTF8Reader.java:368)
at com.ctc.wstx.io.UTF8Reader.read(UTF8Reader.java:111)
at com.ctc.wstx.io.ReaderSource.readInto(ReaderSource.java:87)
at com.ctc.wstx.io.BranchingReaderSource.readInto(BranchingReaderSource.java:57)
at com.ctc.wstx.sr.StreamScanner.loadMoreFromCurrent(StreamScanner.java:1046)
... 26 more
If I terminate the service during this period, the client stops waiting with a similar stack trace immediately, and, as expected, no TCP connection is existing anymore.
Activating WCF logging (see http://msdn.microsoft.com/en-us/library/ms730064.aspx) shows a log according to which WCF thinks, it has delivered the three parts of the WSDL (/?wsdl, /?wsdl=wsdl0, /?wsdl=wsdl1) completely and successfully.
All is running as Administrator, UAC is switched off, it doesn't matter, if I have the firewall off or on or if I have IPv6 off or on. I tried JRE 7_u17 32bit, 7_u25 32bit and 7_u25 64bit.
SoapUI 4.5.1 perfectly communicates with the service locally on the win7-oid platform.
A WCF client communicates with the service locally and without proxy.
A small Java web service client using the Metro libraries, calling a corresponding WCF web service locally, works fine.
If I install the http proxy Fiddler on the win7-oid platforms and reconfigure my Java client app to use the proxy {-Dhttp.proxyHost=localhost -Dhttp.proxyPort=8888 -Dhttp.nonProxyHosts=""}, all is fine.
If the client side is on the XP box and the service on the W7oid one or the other way around, remotely accessing the WCF service works fine without any tricks.
Running out of imagination, what may be the cause for this strange behaviour, I'd like to ask the following questions:
- is there anybody out there, who experienced a similar problem
- any propositions, which Windows mechanism could interfere in the described manner
- any propositions, which other experiments I could take on to get nearer to a solution
- which additional diagnostic measures should I take to boil it down to the very problem [and the solution, I hope]
The symptoms above show, that the problem
arises during retrieval of [parts of] the WSDL
occurs, when directly using a W7oid network connection
.
This gave rise of a further analysis of what happened on the TCP level.
First of all, it was not possible to see any local IP traffic of my web service connection with Wireshark 1.10.2. Even the IP traffic via the physical IP interface was not visible. Also, most of the other at least somehow freely available network anaysers did not seem to support analysis of IP traffic on the loopback interface of W7 and Windows 2008 Server.
Finally, I was able to get a bit of more insight with the trial versions of CommView and LocalNetworkMonitor:
also IP traffic, configured to use the physical IP interface is [secretly] routed via the local network stack as if it were a loopback connection.
such loopback-like IP traffic seems to work on a technically different IP stack on W7oid platforms. Otherwise, tools would not distinguish between the two situations.
on the TCP level, the client begins with opening a http-TCP connection to retrieve "?wsdl". ("?wsdl" contains references to the two large wsdl files "?wsdl=wsdl0" and "?wsdl=wsdl1") Then, almost simultanously, the client requests "?wsdl=wsdl0" on the same first TCP connection (probably due to keep-alive) and a newly opened second TCP connection. One of these two connections is then hanging around unread and unterminated. Only after a timeout of around 200 seconds, some additional chunk of data gets on the way and the TCP connections are both closed (immediately followed by the client stack trace above).
Conclusions:
At least with HTTP-keep-alive, which is the standard setting for WCF and Metro, the way, W7 and W2k8 server handle HTTP-TCP traffic via the loopback interface and the way, WCF and Metro expect it, do not fit together.
In the given scope, it was not possible to boil it down to the very reason. However, it seems the W7 loopback network stack is very picky. Even the network monitoring tools have severe problems to offer correctly working solutions.
The workaround...
... was to configure the web service channel to the physical IP interface AND set a high priority IP route on the W7/W2k8 box, which directs traffic to this interface via the IP gateway. Only then could W2k8 have been forced to refrain from loopbacking and really deliver IP traffic to the physical network interface via its "usual" IP stack -- on which everything, ie. web service and tools, works fine.
Are you sure that all connections are being closed properly? The symptoms you describe are often seen in the .NET world when a .Close() was forgotten on a prior response stream.
On later requests, the client ends up blocking while waiting for a connection to become available (due to the HTTP connection limit). http://fiddler2.com/blog/blog/2013/02/28/help!-running-fiddler-fixes-my-app-
Related
I have created a service (WCF) that acts as a backend for a DB. For now it does basic operations such as INSERT, SELECT etc. I have run it locally and now it is time to expose her to the internet and enter 'production'. Is there a best practice to doing so? Bear in mind this service will be hosted on a PC as a Windows Service (not IIS). This is the first time I am putting a Windows Service into production so I am hazy on the details but I think this is the main idea:
On the service: Check for 'rookie' errors such as SQL Injection. Set maximum message sizes to ones marginally higher than the largest message that should be transmitted by my service. Also upgrade self signed X.509 certificate to one issued by a CA. (Where does one store this certificate? Locally on the PC?)
On the PC: Fully patched software (OS etc) and windows firewall with a specific set of rules that allows traffic only on the ports being used (I suppose the safest way to do this is to use the windows tool Allow a program or feature through Windows Firewall ?). Furthermore an updated antivirus running.
On the Network: For the network router, port forward the respective ports being used (the base address is declared as http://localhost:8080 so I guess port 80 for HTTP and 443 for HTTPS? I am using message level Security.)
General precautions: Full message logging on the service to analyze traffic and potential attackers. Also run a Network intrusion detection system such as Snort so that I can sleep a bit better at night.
Am I missing anything obvious? Also should I be hosting in IIS, on security exchange someone said that I would be vulnerable to HTTP attacks if I did not put the code behind a web server. However I have not read this anywhere else
I'm planning on using a wsDualHttpBinding for a WCF service with callbacks. The clients will be a windows form application communicating to the service over the internet. Obviously I have no control over the firewall on the client side, so I'm wondering what is the proper way to set the ClientBaseAddress on the client side?
Right now in my intiial testing I'm running the service and client on the same pc and i am setting the binding as follows
Dim binding As System.ServiceModel.WSDualHttpBinding = Struct.Endpoint.Binding
binding.ClientBaseAddress = New Uri("http://localhost:6667")
But I have a feeling this won't work when deploying over the internet because "localhost" won't translate to the machine address (much less worrying about NAT translation) and that port might be blocked by the clients firewall.
What is the proper way to handle the base address for callbacks to a remote client?
some one tell me if i do not specify ClientBaseAddress then WCF infratructure creates a default client base address at port 80 which is used for the incoming connections from the service. Since port 80 is usually open to firewalls, things should just work.
so just tell me when win form wcf client apps will run then how can i open my custom port like "6667" and also guide me what library or what approach i should use as a result response should come from client side router
to pc and firewall will not block anything. please discuss this issue with real life scenario how people handle this kind of situation in real life. thanks
The proper way is to use TCP transport instead of HTTP transport. Duplex communication over HTTP requires two HTTP connections - one opened from client to server (that's OK) and second opened from server to client. This can work only in scenarios where you have full control over both ends. There is simply too many complications which cannot be avoided just by guessing what address to use like:
Local Windows or third party firewall has to be configured
Permission for application to run - listening on HTTP is not allowed by default unless UAC is turned off or application is running as admin. You must allow listening on the port through netsh or httpcfg (windows XP and 2003) - that again requires admin permissions.
Port can be already used by another application. In case of 80 it can be used by any local web server - for example IIS.
Private networks and network devices - if your client machine is behind the NAT the port forwarding must be configured but what if you have two machines running your application on the same private network? You cannot forward from the same incoming port to two machines.
All these issues can be avoided mostly only when you have control over whole infrastructure. That is the reason why HTTP duplex communication is useful mostly for intranet scenarios and why for example Silverlight offers another implementation where the second connection is not created and Silverlight client instead polls server continuously to check if there is any callback available.
TCP transport requires only single connection from client to server because TCP protocol is natively duplex so the server can call back the client through the same connection. When you deploy a public service you usually have control over infrastructure on the server side so you can make necessary changes in configuration to make it work.
I think this also answers your previous question.
I am new to wcf programming and I have been working on a small project and am having problems with net.tcp port sharing. I am using .net framework 4 and iis 7.
I have two wcf services (serviceA and serviceB) being hosted on our server in separate websites on IIS. Each website has its own .svc file, web.config and bin. If I have each of these services on different net.tcp ports then there is no problem and I can add the service reference to each of them from visual studio on my pc. The services run fine.
However we will soon be starting a project with many more services and we wish to avoid having to open a tcp port for each one so I have been trying to get serviceA and serviceB to port share. If I set them up on the same port then I can access the first service I add but when when I try to access the second service added to the same port i get the following error:
Metadata contains a reference that cannot be resolved:
'net.tcp://myserver/serviceB.svc'. The socket connection was aborted. This
could be caused by an error processing your message or a receive
timeout being exceeded by the remote host, or an underlying network
resource issue. Local socket timeout was **. An
existing connection was forcibly closed by the remote host If the
service is defined in the current solution, try building the solution
and adding the service reference again.
I can not work out what is going wrong. I have done a lot of searching on the subject and I have made sure that the following services are running:
Windows Process Activation Service
Net.Tcp Port Sharing Service
Net.Tcp Listener Adaptor
In addition net.tcp is an enabled protocol in the website's advanced settings. My current best guess is that it might have something to do with how I have defined the net.tcp bindings in IIS manager. Both of my websites running their independant services have the following: 808:*(net.tcp) is this correct?
As i said earlier the tcp services run fine if set up on two separate ports so the issue must be related to the port sharing. Very grateful for any advice
OK I found the problem I was having. In IIS I had set up each service as its own website and was trying to get those different websites to port share. This would not work.
However I found that if I set up just one website and then added my services as seaprate applications under the website then the port sharing will work. This approach lets me have multiple services as applications under one website.
Check this.
This can be helpful to you.
http://himanshudesai.wordpress.com/2011/06/03/multiple-wcf-services-on-a-single-port/
Hope this helps.
I built a WCF service that exposes itself for a web application, it accepts an object and prints the data on the clients machine. Works fine on my development machine, and the service is up and running on any machine i install it on. I can enter ip address in clients machine web browser and see it is running. Problem is when i send the object to the clients machine it returns an error, that sounds like it could be because of the clients windows firewall. Where would i start at to deal with this problem ?
There was no endpoint listening at http://192.168.1.168:2202/PrintLabel that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details.
And the InnerException: Unable to connect to the remote server
With further research and discussion with people in the community i came to understand that as was mentioned at the bottom of this article.
"Self-hosted HTTP addressing for WCF is not integrated into the Windows firewall. An exception must be added to the firewall configuration to allow inbound connections using a particular URL.
But this SO question led me to a page with how to control Windows Firewall through code to enable my WCF self hosted service to accept an object.
This the link below.
http://www.shafqatahmed.com/2008/01/controlling-win.html
That link was towards the direction i needed, but based on user comments it seemed to have some bugs. A colleague found this link and i believe this technique will be the best solution for this scenario.
Here's the scenario: A client machine has connected to the 'Work network' via VPN (Cisco VPN Client). The work network hosts a machine that has a WCF service with nettcp binding. The client tries to connect to this service and gets an exception as follows:
Could not connect to
net.tcp://workMachine:2010/SomeService.
The connection attempt lasted for a
time span of 00:00:01.3180754. TCP
error code 10061: No connection could
be made because the target machine
actively refused it workMachine:2010.
Things I tried:
Changed the Workgroup of the client
machine to the work network
workgroup
Added domain/username/password for the Windows Networking Password vault, so that it can be used to connect
Changed the wcf service path with an IP address instead of the workMachine name
Checked client machine firewalls and added to allow the wcf client through it
All above failed and didn't work.
Has anyone encountered similar issues?
The client machine is on Windows 7
SecurityMode of the WCF service is set to NONE - so that shouldn't be an issue.
Any insights will be helpful
You may need to supply client credentials explicitly through your proxy object.
Assume that the proxy object in the code below implements one of the ClientBase interfaces.
proxy.ClientCredentials.Windows.ClientCredential.UserName = "clientaccount";
proxy.ClientCredentials.Windows.ClientCredential.Password = "S3cr3t1337Pwd";
Could you - just for testing purposes - expose the same service on the same machine using a HTTP endpoint, and try to connect to that one from your VPN client?
NetTcp is an excellent choice behind the corporate firewall - just don't know how the Cisco VPN client might cause troubles here, that might not show up when using an http-based protocol. Just a wild guess for now, but if you have nothing else to go on, give it a try!
Marc
Just another thought to assist with debugging of these kind of issues, using CMD execute "netstat -a" (you can append the -o switch and find the related process id also) and see if the port in question is currently open, if it isn't you may have an issue with the SMSvcHost.exe (this is the Windows process for managing an IIS hosted TCP Service).
I've had this issue before and rectified it by restarting the following services (obviously you'll need to carefully consider this if you are dealing with a live production system):
NetTcpActivator (Net. Tcp Listening Adapter)
NetTcpPortSharing (Net. Tcp Port Sharing Service)
and possibly if relevant:
NetMsmqActivator (Net. Pipe Listener Adapter)
NetPipeActivator (Net. Pipe Listener Adapter)
Hope this helps someone!
J.