XML serialisation error when connecting to XMPP server - c#

I have an instance of OpenFIre up and running and all is pretty smooth. I can connect to it via Spark as well as a variety of app.
When I wrote my app using the trial version of the Matrix SDK, the client connected perfectly. I am trying to move over to Sharp.XMPP and yet, whenever I try to connect to the server, I get the following error message :
The XML stream could not be negotiated.
When I drill down, I get to the folllwoing inner exception
{"'�', hexadecimal value 0x15, is an invalid character. Line 1,
position 1."}
There seems to be some issue with the response encoding that Sharp.XMPP is expecting.
Does anyone have any idea how to fix this?

Are you trying to connect to an old-style SSL port (usually 5223) with a client that expects to do StartTLS (usually on 5222)?
(0x15 is the TLS content type for "alert", which is likely the response when parsing something that is not TLS.)

Related

OMRON FINS Request Error - "Command Data is too Long"

I am using the RICADO.OMRON library for .NET to be able to connect to and read tags from an OMRON PLC. This usually does work, but I'm running into an issue with this one PLC I am trying to connect to. It is a UDP connection to a PLC, which uses the same base address as another PLC to hop to a different one. It has a specified remote network ID, remote node ID and local network ID to be able to connect.
I see the request message being constructed with all these parameters in the byte array of length 13 (same as any other request, if I'm not mistaken). However, when I read back the response message, this error always shows up:
https://i.stack.imgur.com/wCKQr.png
I've tried looking for more clarity on this exception online but am not having much luck. As far as I know, the request message is being constructed just fine, as it uses the same code for every connection.
Can anybody provide some clarity on the requirements of the request message, and what the command data is?

How to send message from server back to client in C# WebSocket?

I am a junior programmer and it is my first time building a WebSocket application in C#.
I have been following the tutorial from this page:
https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_server
By sending messages from the client to the server, everything works well. However, I want to have a bidirectional connection, so that the server could send messages back to the client in order to see them in the browser.
I have tried the following method, by adding the following lines to the server code:
byte[] tosend = Encoding.ASCII.GetBytes("Message received by server");
stream.Write(tosend, 0, tosend.Length);
I thought the client would receive this message but unfortunately, it return an undefined error and closes the connection.
Could you explain why this method of sedning messages doesn't work and maybe give me a few suggestions?
Thanks!

SMPP BIND ERROR: 0x0000000D in EasySMPP

I am implementing the SMPP client using EasySMPP for .NET
The application is compiling fine but there was no successful outcome and I am getting this weird error
SMPP BIND ERROR: 0x0000000D
What can be done for this, please help.
The error code of 0x0000000D is unfortunately a rather generic "Bind Failed".
To find out what the error codes mean check section 5.1.3, command_status, of the SMPP specification you linked to.
Common causes for getting a "Bind Failed" response are:
Your supplier only allows certain IP addresses to connect
Trying to connect to wrong hostname/port combination
Wrong username/password
To troubleshoot, you could try running Wireshark on your client and take a look at the SMPP PDUs being passed backwards and forwards, if you post the capture on here I'm happy to take a look. Or you could give your supplier a call, they may be able to see something helpful in their server logs.

Enyim Memcached Client does not write / read data

I've installed memcached on Windows as a service, listening on the default port 11211. I know this works, because I can telnet to the server and carry out get / set commands without any problems.
I've then downloaded the Enyim Memcached client (Enyim.Caching.dll, version 2.7) and written a simple test program:
var mcc = new MemcachedClientConfiguration();
mcc.AddServer("127.0.0.1:11211");
mcc.SocketPool.ReceiveTimeout = new TimeSpan(0, 0, 10);
mcc.SocketPool.ConnectionTimeout = new TimeSpan(0, 0, 10);
mcc.SocketPool.DeadTimeout = new TimeSpan(0, 0, 20);
using (MemcachedClient client = new MemcachedClient(mcc))
{
client.Store(StoreMode.Set, "enyimtest", "test value");
Console.WriteLine(client.Get<string>("enyimtest"));
}
I know this connects to my server correctly, as calling the stats command in telnet shows an increase in the number of connections. However, it doesn't call get or set, as the cmd_get and cmd_set stats counters remain constant. The call to client.Get returns null.
The program does not error in any way. Does anyone know what could prevent the Enyim client from working in this situation?
EDIT:
Looks like this is caused by a timeout. Afer configuring log4net to capture the client's logging output, I found it contained the following (in addition to other stack trace items):
2010-12-17 14:26:37,579 [1] ERROR Enyim.Caching.Memcached.MemcachedNode [(null)] - System.IO.IOException: Failed to read from the socket '172.23.0.100:11211'. Error: TimedOut
2010-12-17 14:26:37,626 [1] WARN Enyim.Caching.Memcached.MemcachedNode.InternalPoolImpl [(null)] - Marking node 172.23.0.100:11211 as dead
I still don't understand why it is timing out though?
After an hour or so of playing around, I've found the answer. I used Wireshark to look at the network traffic to and from the server. I noticed that when using the Enyim client, the messages looked nothing like those when using telnet. In particular, I couldn't read the protocol commands going across the wire when using the Enyim client.
Therefore, I concluded that the Enyim client was using a different protocol.
A second protocol was added to the memcached server in version 1.4, which is the binary protocol. Prior to that, only the text protocol was supported. The latest Windows binary I can find for memcached is the one from Jellycan, and it is only version 1.2.6.
The Enyim client is configured to use the Binary protocol by default, which was just ignored by my server as it couldn't be understood.
I added the following line to my test program, and things started working immediately:
mcc.Protocol = MemcachedProtocol.Text;
I ran into the same issue above. I too struggled to find a newer version of memcached for Windows, but did find one eventually.
I've put links to the latest binaries along with other useful resources here.

Unable to push notifications to iPhone in .NET - .PEM certificate problem?

I'm attempting to push notifications to my iPhone, which I've successfully done using PHP. However, I'm unable to open a socket connection to Apple's push servers using C#. I don't think there's a problem with the certificate itself, since I'm able to successfully push notifications using this code in PHP:
$ctx = stream_context_create();
stream_context_set_option($ctx, 'ssl', 'local_cert', 'cert.pem');
$fp = stream_socket_client('ssl://gateway.push.apple.com:2195', $err, $errstr, 60, STREAM_CLIENT_CONNECT, $ctx);
fwrite($fp, $msg);
When I try to authenticate in C# using the code below, Apple closes the connection right away. I get this exception: "Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host."
sslStream.AuthenticateAsClient(hostname, certificatesCollection, SslProtocols.Default, false);
I basically took all my code from this question: C# iPhone push server?
I thought it might be a problem with the certificate since I don't think C# allows you to just load .PEM files programmatically. I used OpenSSL to convert it to a .PFX file, but I still have the same problem.
Any idea how I can troubleshoot this (possible certificate) problem?
This actually turned out to be a problem with .NET 2.0. Not sure exactly what it is, but I compiled in Visual Studio 2008 and everything worked great.

Categories