I am trying to access an NServiceBus service on a work server from a client at home over a VPN connection. The message gets to the service OK but the response queue name has the format
DIRECT=OS:MyHomePCName\private$\MyClientQueueName
The reply message sits in the server's outgoing queue presumably because it can't resolve MyHomePCName. Can I change the response queue name when sending the message to the following format?
DIRECT=TCP:MyHomeIPAddress\private$\MyClientQueueName
Of course I still have the problem of sending the IP address for the VPN connection, but I'm only testing at the moment and don't mind hard coding that in the client for now.
NSB should format it correctly if you put "$queueName#$homeIpAddress". Here is the code it uses:
public static string GetFullPath(string value){
IPAddress ipAddress;
if (IPAddress.TryParse(GetMachineNameFromLogicalName(value), out ipAddress))
{
return (PREFIX_TCP + GetFullPathWithoutPrefix(value));
}
return (PREFIX + GetFullPathWithoutPrefix(value));
}
Related
I am using BizTalk Server SB-Messaging adapter to retreive messages from Azure Service Bus Queue. I have successfully managed to send message to queue myself (using same adapter), and retreive message from queue and do further processing.
Problem arises when a 3rd party software supplier is sending messages to the queue, and for BizTalk Server to retreive and process message. I then receive the following additional "header"-information and control characters in the beginning of the message:
In text: #ACKstringBShttp://schemas.microsoft.com/2003/10/Serialization/?$SOH
Seems like there is some sort of enveloped message, including headers to handle ACKnowledgement of the message to the queue.
SB-Messaging adapter gave following initial error message:
"The WCF service host at address has faulted and as a result no
more messages can be received on the corresponding receive location.
To fix the issue, BizTalk Server will automatically attempt to restart
the service host."
And, another error message:
"No Disassemble stage components can recognize the data."
Did anyone hit this problem before, and, what can be the cause of the problem? Can character encoding be a possible cause of this problem?
Here comes the feedback!
Turned out 3rd party software supplier had a setting to send message as stream, instead of string. Turns out it is a .Net application using BrokeredMessage object. Using string makes message serialized, and meta-data is added to the message. Using stream, no such serialization takes place, and message is kept untouched.
So, problem was using string and automatic serialization when sending to Service Bus Queue.
I have legacy Microsoft.ServiceBus.Messaging clients sending BrokeredMessage Xml content as <string> and I want to receive using the latest Microsoft.Azure.ServiceBus library and Message type.
Using Encoding.UTF8.GetString(message.Body) I get a unusable string prefaced with
#\u0006string\b3http://schemas.microsoft.com/2003/10/Serialization/��#
My approach is to explicitly use XmlDictionaryReader binary deserialization to undo the hidden serialization magic from the legacy library
private static string GetMessageBodyHandlingLegacyBrokeredMessage(Message message)
{
string str = null;
if (message.ContentType == null)
{
using (var reader = XmlDictionaryReader.CreateBinaryReader(
new MemoryStream(message.Body),
null,
XmlDictionaryReaderQuotas.Max))
{
var doc = new XmlDocument();
doc.Load(reader);
str = doc.InnerText;
}
}
else
throw new NotImplementedException("Unhandled Service Bus ContentType " + message.ContentType);
return str;
}
References
https://learn.microsoft.com/en-us/azure/service-bus-messaging/service-bus-messages-payloads#payload-serialization
https://carlos.mendible.com/2016/07/17/step-by-step-net-core-azure-service-bus-and-amqp/
I have implemented TCP socket server which accepts incoming XML messages from client. I could send messages through telnet.
But when I am trying to establish connection and send message through python script, I was getting IOException:CRLF not found before max message length: 2048.So I have added ByteArrayLengthHeaderSerializer to serialize and deserialize, but now I am getting below error.
IOException:Message length 1014132591 exceeds max message length: 2048
Though I am increasing the max message length I am getting IOException:Stream closed after 46 of 1014132591
Could someone let me know how to fix the issue.
final AbstractServerConnectionFactory crLfServer = context.getBean(AbstractServerConnectionFactory.class);
ByteArrayLengthHeaderSerializer serializer = new ByteArrayLengthHeaderSerializer();
serializer.setMaxMessageSize(1000 * 1024);
crLfServer.setSerializer(serializer);
crLfServer.setDeserializer(serializer);
I have implemented using Spring Integration.Below is the snippet for my inbound adapter
#Bean
public TcpReceivingChannelAdapter inboundAdapter(AbstractServerConnectionFactory connectionFactory) {
System.out.println("Creating inbound adapter");
TcpReceivingChannelAdapter inbound = new TcpReceivingChannelAdapter();
inbound.setConnectionFactory(connectionFactory);
//inbound.
inbound.setOutputChannel(fromTcp());
return inbound;
}
I think might be better to send exactly that CRLF in your script after the message. That will be exactly delimiter for the messages to deserialize. This is one what is used by the mentioned Telnet. However you need to come back to the default deserializer in the connection factory configuration.
We used a SMTP server to receive emails, It works perfectly when I send an email to my server from gmail or hotmail. But I'm having problems with a specific company ( I will name it company x), we can read the sender, the recipient, etc, but when it comes to the DATA, the buffered reader hangs forever reading the line on the socket.
This is what happen when I receive the email from the company x:
When I receive a company x's email. they send me the EHLO command
my server returns 500 command unrecognised
the company x's server send the HELO command
my server sends 250 ok to the company x's server.
the copany x's server send me MAIL From: <sender#email.com>
my server sends 250 ok
the company x's server send me RCPT To:<recipient#email.com>
my server sends 250 ok
the company x's server sends DATA
my server sends 354 Start mail input; end with <CRLF>.<CRLF>
At this moment the server hangs forever reading the incoming data (in the in.readline()) and my server throws socket time out exception. (obviously we tried increasing the time out, but it didn't work)
what could be the difference with the company x's SMTP server and the gmail or hotmail server??, what is the problem???
We have the same error with the Java mail server and the james mail server.
The company x, is a bank so they have a high information security level.
here is the code how we send it.
private static final String MESSAGE_SEND_DATA = "354 Start mail input; end with <CRLF>.<CRLF>";
and this is the method that write the comand on the outputstream.
private void write( String message ) {
if( log.isDebugEnabled() ) { log.debug( "Writing: " + message ); }
out.print( message + "\r\n" );
out.flush();
}
we call write after we receive the data commanx from the client.
Most likely it hangs forever awaiting for line terminator symbol. BufferedReader#readLine is platform dependent in terms of line terminators, so it's a poor Reader choice for SMTP server implementation. As a matter of fact, I would advice not to use BufferedReader and PrintWriter for socket-originated streams to avoid platform-dependent issues like this one.
All SMTP server implementations in Java I'm aware of (Apache James, SubethaSMTP) use dedicated Reader implementations, focused on CRLF-terminated lines to read lines from a Socket, in full accordance with RFC 5321. So my advice would be to try one of these readers (for example this one) instead of BufferedReader.
Is there a way of getting the IP address/port of an incoming request? (I don't want the data in the message, but I'd like information from the SIP stack itself, and preferably also the listening point the request had been received on.)
So far I have not find any solution by parsing the Javadocs.
Pending you are using http://java.net/projects/jsip
Cast RequestEvent to gov.nist.javax.sip.RequestEventExt in
public void processRequest(RequestEvent requestEvent) {
RequestEventExt requestEventExt = (RequestEventExt) requestEvent;
requestEventExt.getRemoteIpAddress();
requestEventExt.getRemotePort();
}
Best Regards
Jean
Ok, the problem should be trivial but I can't get to the bottom of it.
I have two users A & B
Their JID's for this example will be A#123 and B#123 where 123 is the IP of the server.
I'm sending a message from A->B using the following code:
chat = chatmanager.createChat(username,
new MessageListener() {
public void processMessage(Chat chat, Message message) {}});
String sendUsername = username + "#123";
Message msgObj = new Message(sendUsername, Message.Type.chat);
msgObj.setBody(message);
chat.sendMessage(msgObj);
I've hardcoded the IP so that I'm 100% sure that I attach the "#123" at the end of the nickname so there are no incorrect JIDs.
So A#123 sends msgObj to B#123. This is how I understood XMPP messaging to work. That you can't send from A->B but it must be A#123 -> B#123.
However, my server seems to think otherwise. It continuously informs me of the following error:
2010.12.27 19:02:52 [org.jivesoftware.openfire.session.LocalOutgoingServerSession
.createOutgoingSession(LocalOutgoingServerSession.java:258)] Error trying to
connect to remote server: A(DNS lookup: A:5269)
java.net.UnknownHostException: A
In both A and B's roster on the Openfire server, they have each other as a contact with the proper JIDs (username#123).
Can anyone provide some insight? I'm lost.
Edit
I'm trying to use Wireshark to catch the XML sent to and from the Openfire server to determine if the recipient of the message is named properly (A#123 instead of A).
Upon using Wireshark, I received this as the XML being transferred:
\302\3469\223\341\3429\000\000\000\000\377\377
I have disabled SSL, I have connected un-securely. I'm not sure why I'm getting SSL type XML, is that what it is?
Turns out the answer to this problem was something that was just overlooked.
In the first line of code:
chat = chatmanager.createChat(username, new MessageListener() {
public void processMessage(Chat chat, Message message) {}
});
I didn't make the variable "username" have the proper IP extension. So it was merely "A" instead of "A#123"
Moving "sendUsername" to the top and Changing "username" to "sendUsername" makes everything work great :)
Silly mistake.
Using IP addresses is almost always more confusing than you think it is.
There's a good chance you have OpenFire misconfigured, so that the IP address isn't a valid hostname. Go into the admin console, under "System Properties", and make sure that the xmpp.domain property is set to your IP address.