I have a server running that runs on TCP/IP. It reads strings and responds with strings. I just wondered if I can just connect via Flash to my server and get some answers from it. My second idea was:
var socket: Socket = new Socket("192.168.0.100", 4847);
socket.writeObject("hello");
var answer: String = socket.readObject();
trace(answer);
Connection is established successfully. But I'm not sure how I send and receive strings now.
Update:
socket.writeUTFBytes("hello\r\n"); seems to work for sending
how to read ? socket.readUTF() ?
I don't know how long the answer might be, it can be short or very long
how about end of line ? It is important for my server since that's how messages are separated. Do I have to send eol via "\r\n" ?
Update 2: This seems to work well
It depends how your server handles the requests and repsonses. For sending and receiving strings use the readUTFBytes and writeUTFBytes.
If you want to use the functions writeObject and readObject your server must know how to handle the AMF serialization. You can find libraries for different languages on this wikipedia page http://en.wikipedia.org/wiki/Action_Message_Format and implement AMF on the server . If you are working on a larger project I would personally recommend that.
Related
I'm trying to store the Soap Input Request (Soap UI Request) in the database for log in ESQL Langage. I'm noob in ESQL .
My flow is Soap Input ==> Compute Node ==> Soap Reply .
I have no idea to do this. Please Help.
Not sure if you still require this or have already found a solution, but thought i'd post anyway.
This is something that has been quite common in several places I have worked. The way we tended to achieve this was by casting the incoming message as a bitstream and then casting it as a character -
DECLARE blobInputMsg BLOB ASBITSTREAM(InputBody CCSID 1208 ENCODING 546);
DECLARE charInputMsg CHAR CAST(blobInputMsg AS CHARACTER CCSID 1208 ENCODING 546);
The CCSID and ENCODING should be taken from the incoming message e.g. InputProperties.CodedCharSetId and InputProperties.Encoding, or defaulted to values suitable for your interfaces.
Have a go at Monitoring. Do the step by step stuff outlined here.
https://www.ibm.com/developerworks/community/blogs/546b8634-f33d-4ed5-834e-e7411faffc7a/entry/auditing_and_logging_messages_using_events_in_ibm_integration_bus_message_broker?lang=en
Be careful with the subscription in MQ as things get concatenated. Use MQExplorer to check your subscription including topic after you've defined it.
Also make sure you run the IIB queue definition scripts as per the install instructions for your version as one of the MQSC commands defines the topic.
Use a separate flow to write the events to your DB. Note in this day and age on Unix systems I'd probably write them to syslog and use ELK or Splunk
I am working on a TCP-based proxy that must first do a REQ/REPLY handshake in json on a given connection. Because JSON is a self-delimiting protocol I reach for Go's json.Decoder to pull off this work which does the job nicely.
Here are the steps I take:
Dial a connection to a remote server
Write a single json request to a remote server (REQ)
Read a single json reply from the same remote server (completing the proxy handshake REPLY)
Upon a valid json handshake, pass the client connection onto another part of the code which will (going forward) switch to a text based protocol from this point on.
The problem is, when json.Decoder reads data into its internal buffer it can potentially read more data than it needs in which case the json.Decoder has a Buffered() method which gives back an io.Reader with the remainder of the data.
This data (available in the Buffered() method) is now the text-based protocol data which needs to get read from the connection after the json hand-shake did its work. But if I pass the connection forward as is without considering the left over buffer, the connection gets into a locked state because it is waiting to read this data which never comes. The code that deals with the text-based protocol expects a net.Conn going forward and once I pass the connection forward (after the json handshake has been made) the code utilizing the connection understands how to speak the text-based protocol at this point on. So there should be a clear boundary of work.
My question is what is the ideal way to solve this issue so I can still take advantage of the json.Decoder, but ensure that when I pass the connection to a different part of the code in my proxy I know the start of the data for the text-based protocol will still be readable. I somehow need to take the remaining data in the json.Decoder's Buffered() method and put that back in front of the connection so it can be properly read going forward.
Any insight is much appreciated.
You can try
type ConnWithBuffIncluded struct{ //Implement net.Conn so can be passed through pipeline
net.Conn
json.Decoder
}
func (x ConnWithBuffIncluded) Read(p []byte) (n int, err error){ //Will Read both sources
return io.MultiReader(x.Decoder.Buffered(), x.Conn).Read(p)
}
I am using JSON to send data from my server to my javascript/html5 client. I use org.codehaus.jettison.json.JSONObject to encode objects and strings on the server side and jquery/ajax to unencode. This has worked fine until today, when I tried to send an inequality symbol ("less than or equal to") from server to client. On the client side, I got this error:
message:
"Unexpected end of input."
When I remove the inequality and re-try, the string goes through fine. I suppose I could create my own special encoding for the 'or equal to' inequality symbols, but that seems to go against the happy grain of leaving encoding up to the parser.
Interesting to note that I do not have the reverse problem: When I 'stringify' from the js side and send a string with an 'or equal' inequality via ajax/json to the server, there is no problem with unencoding on the server side.
Thanks for any help you can offer.
How do you know if a socket server or web server is done transmitting a HTTP GET request when using ProgressEvent.SOCKET_DATA ?
I doing my socket request with socket.writeUTFBytes('GET /index.php HTTP/1.1\r\n');
But the 'answer' is so big that i get multiple ProgressEvent.SOCKET_DATA. How do i know how much data it is supposed to transmit to me ? Or when it's done transmitting ?? Or even how many progressEvents i will get out of this request ? So far I'm using a timer that checks if the server is still transmitting but this isn't a very clean way of doing things..
How do i know how much data it is supposed to transmit to me? Or when it's done transmitting ??
By reading the Content-length header if that is sent by the server, or by waiting until the server closes the connection, or by reading until you've encountered a last-chunk (0<CRLF><CRLF>) if chunked transfer encoding is enabled, or any of the other indications that a full response has been received.
For simplicity, use a HTTPService or if that doesn't fit your needs, use a library that implements an HTTP client.
Or even how many progressEvents i will get out of this request ?
There is no way to tell.
In Internet, I could not found any example for "websocket binary frame" communication using Javascript (as web client) and Java (as web server).
Can you anybody post few example for "websocket binary frame" communication ?
Kaazing WebSocket Gateway has had binary support for quite a while now. Moreover it also works in older browsers that don't support WebSocket natively. And there is support for clients other than JavaScript. So you can do binary over WebSocket using JavaScript, Flash/Flex, Silverlight, .Net, or Java. You can use any browser, the fallback emulation will work in older browsers.
The backend server can be Java or anything that listens on a TCP port.
Jetty has supported binary frames in WebSockets since at least version 7.5.2. Here is a Jetty example that includes binary frames: https://www.eclipse.org/jetty/documentation/9.4.x/jetty-websocket-api-send-message.html
From the server point of view, there is very little difference between sending and receiving binary data, it's just a single opcode change. When sending text, you are limited to UTF-8 encoded data. With binary you don't have that limit.
From the browser point of view, if the browser supports binary data (which really only very recent builds of Chrome support) then sending binary data involves sending an arraybuffer or blob using the send() method on the WebSocket object. Receiving binary data happens automatically if the server sends a binary frame. However, you can select between receiving blobs or arraybuffers by setting the binaryType property on your WebSocket object instance.
I just know how to unwrap the content sent from browser, here is my code:
socket.ondata = function(src,start,end) {
src = src.slice(start,end);
var maskKeys = [src[2],src[3],src[4],src[5]];
var dest = new Array();
for(var i=0;i<src.length-6;i++){
var mKey = maskKeys[i%4];
dest[i] = mKey ^ src[6+i];
}
console.log(new Buffer(dest).toString());
}
Found from here: http://songpengfei.iteye.com/blog/1178310
Link there is a zipped c source code, I change it to node. And now I'm study how to send data to the client.