The client has been disconnected while trying to perform the connection - c#

When trying to connect to a Mosquitto MQTT queue running locally, I get the following error.
Unhandled exception. System.AggregateException: One or more errors occurred. (The client has been disconnected while trying to perform the connection)
---> System.Net.Mqtt.MqttClientException: The client has been disconnected while trying to perform the connection
at System.Net.Mqtt.Sdk.MqttClientImpl.ConnectAsync(MqttClientCredentials credentials, MqttLastWill will, Boolean cleanSession)
I am using the default options when setting up the System.Net.Mqtt.MqttClient.
var config = new MqttConfiguration() {
Port = 1883
};
var client = MqttClient.CreateAsync("localhost", config).Result;
var sessionState = client.ConnectAsync(
new MqttClientCredentials(clientId: "camerasim")).Result;
The following errors show up in the Mosquitto MQTT log.
1644497589: New connection from 172.17.0.1:56792 on port 1883.
1644497589: New client connected from 172.17.0.1:56792 as camerasim (p2, c0, k0).
1644497589: Bad socket read/write on client camerasim: Invalid arguments provided.

The error you are seeing is most likely the result of a change made in Mosquitto 2.0.12:
Fix max_keepalive not applying to MQTT v3.1.1 and v3.1 connections. These clients are now rejected if their keepalive value exceeds max_keepalive. This option allows CVE-2020-13849, which is for the MQTT v3.1.1 protocol itself rather than an implementation, to be addressed.
A change made in 2.0.9 also comes into play:
Fix max_keepalive option not applying to clients connecting with keepalive set to 0. Closes #2117.
These changes were made to address an issue with the MQTT protocol itself which permits a denial of service attack (CVE-2020-13849).
The default value for max_keepalive is 65535 so this change means that attempting to connect with keep alive set to 0 (meaning no keepalive) will fail unless mosquitto.conf specifies max_keepalive 0. Unfortunately the error logged (Bad socket read/write on client XXXXXYYYYY: Invalid arguments provided.) does not really highlight the cause.
There are two available solutions:
Specify max_keepalive 0 in mosquitto.conf (Mosquitto 2.0.13 or later).
When connecting specify a keep alive between 1 and 65535. In xamarin/mqtt this means adding KeepAliveSecs to your config; this defaults to 0.
Note that setting KeepAliveSecs = 1 (as per your answer) will allow you to connect but is probably a little short for most users (KeepAliveSecs = 60 may be more appropriate). e.g.
var configuration = new MqttConfiguration {
Port = 1883,
KeepAliveSecs = 60,
WaitTimeoutSecs = 2,
};
I realise that you have already found a solution to this but as it's likely to affect others I thought it was worth explaining the root cause of the issue. Many MQTT libraries default keep alive to 0 so will be impacted (e.g. Go Paho had an issue logged).

I was able to successfully make a connection by changing the default KeepAliveSecs property when setting up the MqttConfiguration.
var config = new MqttConfiguration() {
KeepAliveSecs = 1,
Port = 1883
};

Related

CommunicationException: An error occurred on client side while making the HTTP request (HTTP.SYS) to third-party WebService

I'm from Brazil and our government released a WebService meant to inform employees' payroll that's called eSocial. I'm developing a solution to communicate with this service for about a year now and I found this error in some customers' machines while trying to send information to the government WebService:
System.ServiceModel.CommunicationException:
An error occurred while making the HTTP request to 'https://webservices.producaorestrita.esocial.gov.br/servicos/empregador/enviarloteeventos/WsEnviarLoteEventos.svc'. This could be due to the fact that the server certificate is not configured properly with HTTP.SYS in the HTTPS case. This could also be caused by a mismatch of the security binding between the client and the server.
---> System.Net.WebException: The underlying connection was closed: The connection was closed unexpectedly.
---> System.IO.IOException: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host.
---> System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host at System.Net.Sockets.Socket.Receive(Byte[] buffer, Int32 offset, Int32 size, SocketFlags socketFlags)...
In most machines our program is working perfectly, the error arises just on some computers. My target platform is .NET Framework 4.7.
During my researches I've found two solutions for the problem:
Set the property ServicePointManager.SecurityProtocol (https://stackoverflow.com/a/33084791/8133067);
Let Windows Update install the updates needed (https://stackoverflow.com/a/45494549).
In case of the first solution: eSocial WebService uses the TLS 1.2 security protocol, but this is not always the default machine configuration. I already did this in the code and did not solve in most cases:
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls |
SecurityProtocolType.Tls11 |
SecurityProtocolType.Tls12;
In case of the second solution: In the research I did the problem could happen on computers with an outdated Windows 7, and theoretically the update via Windows Update would solve, but in most cases did not solve, and I have even caught some cases of this error in Windows 10.
I even did a test program, with the message log and trace log turned on, to see if I could get any more information, but the only other thing I found out (because of tracing) is that the error occurs when the message is sent by the channel (communication channel with the WebService).
Here is the code I'm using to instantiate and call the service:
const string UrlSvcBase = #"https://webservices.{0}.esocial.gov.br/servicos/empregador/{1}";
string urlServico = String.Format(UrlSvcBase, "producaorestrita", #"enviarloteeventos/WsEnviarLoteEventos.svc");
var address = new EndpointAddress(urlServico);
//var binding = new BasicHttpBinding(BasicHttpsSecurityMode.Transport);
var binding = new BasicHttpsBinding(); //Available since .NET Framework 4.5
binding.Security.Transport.ClientCredentialType = HttpClientCredentialType.Certificate;
// Manual de Orientação do Desenvolvedor v1.4, página 39, item '5.4.5. Validações aplicadas':
// "O tamanho limite da mensagem SOAP é 750 kbytes."
// O valor padrão da propriedade MaxReceivedMessageSize é 65.536,
// que é alterado então para 750 KB * 1024 = 768.000 bytes.
// Caso contrário, ocorre a exceção:
// Exception: System.ServiceModel.CommunicationException
// InnerException: System.Exception {System.ServiceModel.QuotaExceededException}
// "The maximum message size quota for incoming messages (65536) has been exceeded.
// To increase the quota, use the MaxReceivedMessageSize property on the appropriate binding element."
// HResult: -2146233087 (0x80131501)
binding.MaxReceivedMessageSize = 768000;
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls |
SecurityProtocolType.Tls11 |
SecurityProtocolType.Tls12;
var wsClient = new WsEnviar.ServicoEnviarLoteEventosClient(binding, address);
// 'certificado' variable's type is X509Certificate2.
wsClient.ClientCredentials.ClientCertificate.Certificate = certificado;
wsClient.Open();
// 'lote' variable's type is XElement.
var retorno = wsClient.EnviarLoteEventos(lote);
wsClient.Close();
Does anyone have any idea what might cause this error, or any idea of what else I can do to try to figure out the cause of the problem?
[EDIT]
My question was flagged as a possible duplicate of that one:
WCF Error "This could be due to the fact that the server certificate is not configured properly with HTTP.SYS in the HTTPS case"
But, I had already tried almost all those solutions without success (actually, you can see that question already linked on my original post), that's why I've posted a new question, and there is a fundamental difference because in that question the service was made by the user and in my case the service is third-party. Fortunately I've got the answer somewhere else, so I'll post it here.
I've posted that question on Stack Overflow in Portuguese too:
https://pt.stackoverflow.com/q/318351/86952
And there I've got the answer from the user EProgrammerNotFound (https://stackoverflow.com/users/2087187), in the comments section.
After some testing using Fiddler, he found out that there seems to be a bug in .NET Framework because in some scenarios it was not doing a fallback to a previous version of security protocol.
So, even if I've designated the security protocol property to use TLS versions 1.2, 1.1 and 1.0:
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls |
SecurityProtocolType.Tls11 |
SecurityProtocolType.Tls12;
if the connection using TLS 1.2 fails for some reason (in that specific environment that I could not replicate, but occurred in some customers), it stops without trying TLS 1.1 and after that TLS 1.0, and then we get that error.
So, I've changed my code to use only TLS 1.0 directly, and it solved the case on the problematic machines:
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls;
On my question at SOPT I've also got an answer from the user Jonas Giehl (https://pt.stackoverflow.com/a/324254/86952) that suggested a code that would try each security protocol manually, something that I thought of also but didn't had the time to try.
There goes his code (modified a little bit):
// Stack with protocols we are going to try.
Stack<SecurityProtocolType> protocolsToTry = new Stack<SecurityProtocolType>();
protocolsToTry.Push(SecurityProtocolType.Tls);
protocolsToTry.Push(SecurityProtocolType.Tls11);
protocolsToTry.Push(SecurityProtocolType.Tls12);
bool tryAgain = false;
do
{
// Set the protocol we are going to try now.
ServicePointManager.SecurityProtocol = protocolsToTry.Pop();
try
{
// Tries to call the service using the current protocol.
// If no exceptions are threw, we are ready to exit the loop.
CallService();
tryAgain = false;
}
catch (CommunicationException ex)
{
tryAgain = true;
}
} while(tryAgain && protocolsToTry.Count() > 0);

IBM MQ Server Setup to Create CCDT file used by .NET Client

I need to use CCDT file for MQ.NET client to connect to MQ Server, both are running locally, but got error below.
IBM.WMQ.MQException: MQRC_Q_MGR_NAME_ERROR CompCode: 2, Reason: 2058
Please find below the server setup, and MQ.NET client.
Server Setup
I setup and created CCDT file following the links below:
Setting up the server using IBM MQ Explorer
Server-connection Channel: LOCAL.DEF.SVRCONN
MCA User ID: I tried either omitting it or providing it. And either member of mqm or not of it.
Setting up the client using IBM MQ Explorer
Clinet channe: LOCAL.DEF.SVRCONN
Queue Manager name: LocalQM
Connection name: 192.168.1.9 (1415)
192.168.1.9 is localhost address
1415 is queue manager, LocalQM, TCP port.
IBM MQ.NET
The code is below from here
MQQueueManager qm = null;
System.Environment.SetEnvironmentVariable("MQCHLLIB", "C:\\ProgramData\\IBM\\MQ\\qmgrs\\LocalQM\\#ipcc");
System.Environment.SetEnvironmentVariable("MQCHLTAB", "AMQCLCHL.TAB");
try
{
Hashtable props = new Hashtable();
props.Add(MQC.TRANSPORT_PROPERTY, MQC.TRANSPORT_MQSERIES_CLIENT);
qm = new MQQueueManager("LocalQM",props);
MQQueue queue1 = qm.AccessQueue("LocalQueue", MQC.MQOO_OUTPUT | MQC.MQOO_FAIL_IF_QUIESCING);
MQMessage msg = new MQMessage();
msg.WriteUTF("Hello this message is from .net client");
queue1.Put(msg);
queue1.Close();
qm.Disconnect();
}
catch (Exception ex)
{
Console.Write(ex);
}
IBM MQ V8 on Windows 10
MQ.NET Client V8 on Windows 10
Creating a client channel definition table
Using a client channel definition table with .NET
UPDATE
If I change to below without using CCDT, it works.
var properties = new Hashtable
{
{MQC.TRANSPORT_PROPERTY, MQC.TRANSPORT_MQSERIES_MANAGED },
{ MQC.HOST_NAME_PROPERTY, "192.168.1.9" }, //"localhost" },
{ MQC.PORT_PROPERTY, "1415"},
{ MQC.CHANNEL_PROPERTY, "LOCAL.DEF.SVRCONN" },
{MQC.USER_ID_PROPERTY, "xxx" }, //usrename
{MQC.PASSWORD_PROPERTY, "xxx" } //password
};
_queueManager = new MQQueueManager(_queueManagerName, properties);
UPDATE 2
I changed queue manager to LocalQM
C:\Users\'#.lp\source>SET MQCHLLIB=C:\ProgramData\IBM\MQ\qmgrs\LocalQM\#ipcc
C:\Users\'#.lp\source>SET MQCHLTAB=AMQCLCHL.TAB
C:\Users\'#.lp\source>echo DIS CHL(LOCAL.DEF.SVRCONN) CHLTYPE(CLNTCONN) ALL | runmqsc -n
5724-H72 (C) Copyright IBM Corp. 1994, 2015.
Starting local MQSC for 'AMQCLCHL.TAB '.
1 : DIS CHL(LOCAL.DEF.SVRCONN) CHLTYPE(CLNTCONN) ALL
AMQ8414: Display Channel details.
CHANNEL(LOCAL.DEF.SVRCONN) CHLTYPE(CLNTCONN)
AFFINITY(PREFERRED) ALTDATE(2018-04-16)
ALTTIME(22.16.03) CERTLABL( )
CLNTWGHT(0) COMPHDR(NONE)
COMPMSG(NONE) CONNAME(192.168.1.9 (1415))
DEFRECON(NO) DESCR( )
HBINT(300) KAINT(AUTO)
LOCLADDR( ) MAXMSGL(4194304)
MODENAME( ) PASSWORD( )
QMNAME(LocalQM) RCVDATA( )
RCVEXIT( ) SCYDATA( )
SCYEXIT( ) SENDDATA( )
SENDEXIT( ) SHARECNV(10)
SSLCIPH( ) SSLPEER( )
TPNAME( ) TRPTYPE(TCP)
USERID( )
No commands have a syntax error.
C:\Users\'#.lp\source>
UPDATE 3: MQRC_NOT_AUTHORIZED is Not resolved
I changed
192.168.1.9 (1415) -> 192.168.1.9(1415)
Put AMQCLCHL.TAB also to C:\ProgramData\IBM\MQ (I don't know why which might not be correct, because error on log file:
AMQ9518: File 'C:\ProgramData\IBM\MQ\AMQCLCHL.TAB' not found.
)
3 I tried
MCA User Id ->
1 mqlclient who is memeber of mqm
2 mqlclient who is not memeber of mqm
3 empty
But still got error. Below is exception and error for 3.1
IBM.WMQ.MQException: MQRC_NOT_AUTHORIZED
----- cmqxrsrv.c : 2356 -------------------------------------------------------
17/04/2018 23:50:44 - Process(1848.16) User(SYSTEM) Program(amqzlaa0.exe)
Host(APPLE) Installation(Installation1)
VRMF(8.0.0.5) QMgr(LocalQM)
AMQ5540: Application 'bin\Debug\Producer.exe' did not supply a user ID
and password
EXPLANATION:
The queue manager is configured to require a user ID and password, but none was
supplied.
ACTION:
Ensure that the application provides a valid user ID and password, or change
the queue manager configuration to OPTIONAL to allow applications to connect
which have not supplied a user ID and password.
----- amqzfuca.c : 4311 -------------------------------------------------------
17/04/2018 23:50:44 - Process(1848.16) User(SYSTEM) Program(amqzlaa0.exe)
Host(APPLE) Installation(Installation1)
VRMF(8.0.0.5) QMgr(LocalQM)
AMQ5541: The failed authentication check was caused by the queue manager
CONNAUTH CHCKCLNT(REQDADM) configuration.
EXPLANATION:
The user ID 'mqclient' and its password were checked because the user ID is
privileged and the queue manager connection authority (CONNAUTH) configuration
refers to an authentication information (AUTHINFO) object named
'SYSTEM.DEFAULT.AUTHINFO.IDPWOS' with CHCKCLNT(REQDADM).
This message accompanies a previous error to clarify the reason for the user ID
and password check.
ACTION:
Refer to the previous error for more information.
Ensure that a password is specified by the client application and that the
password is correct for the user ID. The authentication configuration of the
queue manager connection determines the user ID repository. For example, the
local operating system user database or an LDAP server.
To avoid the authentication check, you can either use an unprivileged user ID
or amend the authentication configuration of the queue manager. You can amend
the CHCKCLNT attribute in the CHLAUTH record, but you should generally not
allow unauthenticated remote access.
-------------------------------------------------------------------------------
17/04/2018 23:50:45 - Process(14900.9) User(SYSTEM) Program(amqrmppa.exe)
Host(APPLE) Installation(Installation1)
VRMF(8.0.0.5) QMgr(LocalQM)
AMQ9557: Queue Manager User ID initialization failed for 'mqclient'.
EXPLANATION:
The call to initialize the User ID 'mqclient' failed with CompCode 2 and Reason
2035.
ACTION:
Correct the error and try again.
----- cmqxrsrv.c : 2356 -------------------------------------------------------
OP added the following information to the question in UPDATE 2:
SET MQCHLLIB=C:\ProgramData\IBM\MQ\qmgrs\QM1\#ipcc
SET MQCHLTAB=AMQCLCHL.TAB
echo DIS CHL(LOCAL.DEF.SVRCONN) CHLTYPE(CLNTCONN) ALL | runmqsc -n
I see two possible issues with the CCDT:
You have a space in the CONNAME between the IP and the open parenthesis. This may be causing MQ to disregard the port 1415 and use the default port 1414, it also may ignore the space and it may not be a problem, I have never tested with a space.
COMPMSG(NONE) CONNAME(192.168.1.9 (1415))
The QMNAME of the CLNTCONN channel should match what you are specifying in the call to new MQQueueManager, so this should say QM1 not LocalQM, this is likely the direct reason for your 2058 error, but #1 may cause an issue as well once you fix #2.
QMNAME(LocalQM) RCVDATA( )
There are also other uses for QMNAME where you can specify a group name or a blank. See my answer to "Connecting to IBM MQ using CCDT file in JMS
" for more details on this. The answer is related to JMS but the information presented for the setQueueManager would be the same as the first parameter to your call to new MQQueueManager.
Generally speaking, reason code of 2058 (MQRC_Q_MGR_NAME_ERROR) means that you have an invalid queue manager name or that the server does not have that particular queue manager. Check the spelling of the queue manager name that you inputted. Also, queue manager names are case sensitive (e.g. MQA1 is not the same as mqa1).
Also, every queue manager will have its own port #. i.e. 1414, 1415, 1416, etc. So, if there is more than 1 queue manager running on that server then make sure you are using the correct port.
System.Environment.SetEnvironmentVariable("MQCHLLIB", "C:\\ProgramData\\IBM\\MQ\\qmgrs\\QM1\\#ipcc");
System.Environment.SetEnvironmentVariable("MQCHLTAB", "AMQCLCHL.TAB");
Try setting the environment variables before starting your program rather than from inside your program. I have found weird issues in Windows and/or .NET with setting environment variables inside a program - sometimes it works, sometimes it doesn't.
Finally, are you running your application on the same server as where the queue manager is running? If so, then connect in 'bindings mode' rather than 'client mode'. Bindings mode will be way faster as there is no network involved.

Override the userid send by Websphere MQ Client in C# Windows application

I am trying to connect to a test instance of a Websphere MQ 7.5 server (on a Windows domain) from a C# application using the full MQ Client install, but I've had no luck. I keep getting the error code 2035 MQRC_NOT_AUTHORIZED from the MQ server. Initially I tried the code below:
string QueueManagerName = "myNewQManager";
MQEnvironment.Hostname = "tst-mqsvr";
MQEnvironment.Channel = "test.channel";
MQEnvironment.Port = 1414;
MQEnvironment.UserId = "domainUser";
MQEnvironment.Password = "********";
//set transport properties.
MQEnvironment.properties[MQC.TRANSPORT_PROPERTY] = MQC.TRANSPORT_MQSERIES_CLIENT;
try
{
queueManager = new MQQueueManager(QueueManagerName);
}
catch(MQException mqexp)
{
//I get the error code 2035
log.Error(mqexp)
}
changing to this doesn't work either:
string QueueManagerName = "myNewQManager";
var queueProperties = new Hashtable();
queueProperties[MQC.TRANSPORT_PROPERTY] = MQC.TRANSPORT_MQSERIES_CLIENT;
queueProperties[MQC.HOST_NAME_PROPERTY] = "tst-mqsvr";
queueProperties[MQC.PORT_PROPERTY] = "1414";
queueProperties[MQC.CHANNEL_PROPERTY] = "test.channel";
queueProperties[MQC.USER_ID_PROPERTY] = "domainUser";
queueProperties[MQC.PASSWORD_PROPERTY] = "*********";
try
{
queueManager = new MQQueueManager(QueueManagerName, queueProperties);
}
catch(MQException mqexp)
{
//I still get the error code 2035
log.Error(mqexp)
}
This error goes away and I can connect/put/get messages from my queue if
I manually set the MCAUSER on my channel, or
I run the application as the domain user who set up the MQ server (using RunAs)
However, I will not be able to use either of these two workarounds for the production set up. I am assuming I'm getting the error code 2035 because the MQ client is sending the wrong user-id. I need to be able to override (or at least determine) the flowed userid during server connection. How do I go about this?
Edit: I got the errors below in my AMQERR01.log file
-------------------------------------------------------------------------------
7/6/2016 13:06:14 - Process(1380.10) User(MUSR_MQADMIN) Program(amqzlaa0.exe)
Host(TST-MQSVR) Installation(DefaultInstall)
VRMF(7.5.0.2) QMgr(MYNEWQMANAGER)
AMQ8075: Authorization failed because the SID for entity 'sinistrian' cannot be
obtained.
EXPLANATION:
The Object Authority Manager was unable to obtain a SID for the specified
entity. This could be because the local machine is not in the domain to locate
the entity, or because the entity does not exist.
ACTION:
Ensure that the entity is valid, and that all necessary domain controllers are
available. This might mean creating the entity on the local machine.
----- amqzfubn.c : 2273 -------------------------------------------------------
7/6/2016 13:06:14 - Process(1380.10) User(MUSR_MQADMIN) Program(amqzlaa0.exe)
Host(TST-MQSVR) Installation(DefaultInstall)
VRMF(7.5.0.2) QMgr(MYNEWQMANAGER)
AMQ8073: Authorization failed because SID: ((None)) could not be resolved.
EXPLANATION:
The Object Authority Manager was unable to resolve the specified SID into
entity and domain information.
ACTION:
Ensure that the application provides a SID that is recognized on this system,
that all necessary domain controllers are available, and that the security
policy is set as you required.
----- amqzfubn.c : 4397 -------------------------------------------------------
7/6/2016 13:06:14 - Process(3008.3) User(MUSR_MQADMIN) Program(amqrmppa.exe)
Host(TST-MQSVR) Installation(DefaultInstall)
VRMF(7.5.0.2) QMgr(MYNEWQMANAGER)
AMQ9557: Queue Manager User ID initialization failed.
EXPLANATION:
The call to initialize the User ID failed with CompCode 2 and Reason 2035.
ACTION:
Correct the error and try again.
----- cmqxrsrv.c : 1975 -------------------------------------------------------
7/6/2016 13:06:14 - Process(3008.3) User(MUSR_MQADMIN) Program(amqrmppa.exe)
Host(TST-MQSVR) Installation(DefaultInstall)
VRMF(7.5.0.2) QMgr(MYNEWQMANAGER)
AMQ9999: Channel 'TEST.CHANNEL' to host 'WKS-L450 (192.168.10.23)' ended
abnormally.
EXPLANATION:
The channel program running under process ID 3008(2192) for channel
'TEST.CHANNEL' ended abnormally. The host name is 'WKS-L450 (192.168.10.23)';
in some cases the host name cannot be determined and so is shown as '????'.
ACTION:
Look at previous error messages for the channel program in the error logs to
determine the cause of the failure. Note that this message can be excluded
completely or suppressed by tuning the "ExcludeMessage" or "SuppressMessage"
attributes under the "QMErrorLog" stanza in qm.ini. Further information can be
found in the System Administration Guide.
Until version 7.5, MQ client always flows the logged-in UserId and not the UserId specified by the application, to queue manager for authorization. You will need a security exit for this scenario.
This changed in MQ v8 where UserId specified by the application is flowed to the queue manager for authorization check. More details here: https://www.ibm.com/support/knowledgecenter/SSFKSJ_8.0.0/com.ibm.mq.sec.doc/q113260_.htm
You could use the MQS_REPORT_NOAUTH or MQSAUTHERRORS setting to get more info the authority failure.

Correcty handle Expectation failed (417) and change Expect100Continue in WCF client app

My application is a C# Windows service that consumes a WCF service. When the first "Expectation failed (417)" error occurs, I change both ServicePointManager.Expect100Continue and ServicePoint.Expect100Continue to false:
try
{
//ServicePointManager.Expect100Continue = false; // If uncomment all work
var svc = new ServiceClient();
svc.GetData(); // first error
}
catch (ProtocolException pex)
{
if (pex.Message.Contains("(417)"))
{
ServicePointManager.Expect100Continue = false;
var sp = ServicePointManager.FindServicePoint(new Uri(#"http://addr.to.service/service.svc"));
sp.Expect100Continue = false;
var svc = new ServiceClient();
svc.GetData(); // second same error
}
}
However, the second call to the service also fails. But if I set Expect100Continue to false before any connection, communication with the service works correctly.
Is this way correctly to handle Expect100Continue errors? I need the application adapts automatically without user action. What am I forgetting to do this work?
Most of the settings on ServicePointManager are treated as the default values applied on all NEW ServicePoints that are created after that point in the application's life. In the case where you change the setting after seeing the error, you are not actually changing anything on existing ServicePoint instances, including the instance associated with the connection used by WCF in this case.
In your Sample code you are calling ServicePointManager.FindServicePoint to try to find the correct ServicePoint. However, FindServicePoint has several overloads and it is easy to use that API incorrectly. For instance, FindServicePoint will try to take into account things http/https, the host you are connecting to, your proxy configuration, etc. If you are not providing the correct parameters to FindServicePoint, you can easily end up getting the wrong ServicePoint returned to you and your settings will not be applied to the ServicePoint you intended to change.
I would recommend that you use the FindServicePoint overload that takes an IWebProxy object to ensure that you get the right ServicePoint. In most cases, you should be able to pass in WebRequest.DefaultWebProxy as the IWebProxy object.
From the MSDN documentation of ServicePointManager.Expect100Continue,
Changing the value of this property does not affect existing ServicePoint objects. Only new ServicePoint objects created after the change are affected. Therefore changing the value on the existing WCF client will have no effect. You need to create a new WCF client, then call GetData()

WCF NetTcpBinding - from Microsoft tutorial - getting timeout

I built a project as descripted in this URL:
http://msdn.microsoft.com/en-us/library/ms734784.aspx
I used the app.config version. But using the code-Version does not change anything (the timeout-error still occurs).
To create the ServiceHost I used the following code:
this.serviceHost = new ServiceHost(typeof(Calculator));
// Open the ServiceHostBase to create listeners and start
// listening for messages.
this.serviceHost.Open();
On the client side I used the following code:
ChannelFactory<ICalculator> factory = new ChannelFactory<ICalculator>("netTcp_ICalculator");
ICalculator communicationChannel = this.factory.CreateChannel();
string test = communicationChannel.GetData(5);
On the last line the program waits one minute, then I get a timeout:
This request operation sent to net.tcp://localhost:8008/Calculator did not
receive a reply within the configured timeout (00:01:00).
The time allotted to this operation may have been a portion
of a longer timeout. This may be because the service is still
processing the operation or because the service was unable to
send a reply message. Please consider increasing the operation
timeout (by casting the channel/proxy to IContextChannel and
setting the OperationTimeout property) and ensure that the service
is able to connect to the client.
The class Calculator and the interface exist. Besides this timeout I get no other error. I set a breakpoint at the GetData method, but the breakpoint was not hit.
I have tried to change the portnumber used for the client from 8008 to 8009, but let the endpoint for the server at 8008. I wanted to test if the client tries to reach the server. Then I get the error that the other side is not answering (EndpointNotFoundException).
When changing the client port back to 8008 I get the Timeout error again.
Is there anything wrong with my code?
How can I ensure that the server can reach the client?
Client and server are in the same test application.
Thank you for your help!
EDIT:
I have now deleted the app.config settings. And tried to build the server and client by using the sourcecode. To build the server was no problem. But building the client is a problem.
There is no way to call:
CalculatorClient cc = new CalculatorClient(myBinding, myEndpointAddress);
The compiler does not know CalculatorClient.
Can I use the following instead?
NetTcpBinding myBinding = new NetTcpBinding();
myBinding.Security.Mode = SecurityMode.None;
// Create the address string, or get it from configuration.
string tcpUri = "net.tcp://localhost:8008/Calculator";
// Create an endpoint address with the address.
EndpointAddress myEndpointAddress = new EndpointAddress(tcpUri);
ChannelFactory<ICalculator> factory = new ChannelFactory<ICalculator>(myBinding, myEndpointAddress);
factory.Open();
ICalculator communicationChannel = this.factory.CreateChannel();
string test = communicationChannel.GetData(5);
I get again an exception at the last line :(
SOLVED:
Ok, the problem is solved. I needed to call the WCF host initialization via an own thread:
hostThread = new Thread(this.createService);
hostThread.Start();
Now everything works fine!
Thanks for all your help!
You are not adding any endpoints to the service.
You did not include the part of the example code that adds the service endpoint:
Uri tcpUri = new Uri("net.tcp://localhost:8008/Calculator");
// Create the ServiceHost.
ServiceHost sh = new ServiceHost(typeof(Calculator), tcpUri);
// Create a binding that uses TCP and set the security mode to none.
NetTcpBinding b = new NetTcpBinding();
b.Security.Mode = SecurityMode.None;
// Add an endpoint to the service.
sh.AddServiceEndpoint(typeof(ICalculator), b, "");
// Open the service and wait for calls.
sh.Open();
Edit: Same goes for your client. You have to specify an endpoint addresses
// Create a channel factory.
NetTcpBinding b = new NetTcpBinding();
b.Security.Mode = SecurityMode.None;
Uri tcpUri = new Uri("net.tcp://localhost:8008/Calculator");
ChannelFactory<ICalculator> myChannelFactory = new ChannelFactory<ICalculator>(b,new EndpointAddress(tcpUri));
// Create a channel.
ICalculator calculator = myChannelFactory.CreateChannel();
Edit2: I can't currently test this code... Will give it a try tomorrow morning.
Are you using Windows 7?
If so, you likely need to run Visual Studio as an Administrator. UAC will not let you create the service endpoint unless you are a running as an administrator.

Categories

Resources