how can i understand that all message is sent using Actionscript? - actionscript-3

Using TCP protocol. Client is Flash. Server is Java (on Linux).
Is there anyway to understand if a message is successfully sent to target server in client (Actionscript 3) ?

I guess you are using the Socket class for this, which will broadcast events. To make sure your data is sent succesfully, have the server send back some confirmation data. The Socket class will broadcast a ProgressEvent.SOCKET_DATA event which you can listen for.
Refer to the Socket manpage

Related

How to send json data over http

I am new to http protocol. When we are sending json message over http to server, How we need to send ?
we need to send the data from different port each time
OR
we can send data form a single port in each time.
If I want to use existing connection to send data in future then whether it is possible or not ?
There is no reason why you would create a TCP socket for each piece of data you want to send — and this has nothing to do with HTTP — and particularly not through a different port each time. In fact, once you hace the socket created and you have connected to the server you should in principle always talk to the server through that socket.
Also, the HTTP protocol uses the port 80, and HTTPS uses 443. That number does not change on demand. Of course you can send HTTP requests through any available port you want and some services even run on special ports using HTTP as the communication protocol but normaly HTTP is 80. See the /etc/services file on linux and read about getaddrinfo().

AS3 - Datagramsocket without port

I want to make multiplayer game, and I want it to use UDP sockets. Because of that, I want to use DatagramSocket. The problem is that DatagramSocket needs to be bound to a port on both sides. Is there a way to create a server - client program with UDP that does not need the client to portforward? (Like Serversocket and Socket).
Remember that UDP is connectionless. You send a packet of data to some IP address and hope it knows what to do with it once it gets to the targeted machine. But actually once it's on the machine it has no idea where to go from there, is there an application that's interested in these packets? And this is precisely why you need to specify a port number that is registered to forward packets to specific application on the machine.
Send a packet to myself to the application running on port 7000: 127.0.0.1 : 7000

TUN/TAP write back to tunnel

My app is using a TUN say tun0. In the design, my app will receive an UDP which includes an full IP layer, then I will take the IP layer out and then use 'file write' to put them into my own tun0 device, supposedly in design, I should can read the packet out again from tun0.
Now the situation is I can see through tcpdump the package is wrote into the tunnel, but I couldn't read them back.
Something wrong with tunnel setting or route setting?
Thanks in advance
Yang
Your second tun0 is not a FIFO queue. You may have a problem in your design of how and why your are using the second tun0 device. Clarify why you are using it and which process should be reading. The proper approach should flow from that clarification.
If you want to read the data you send into you have some options.
Connect tun0 to an TCP or UDP echo service when you open it. This will then send you back the packets you stuff into it.
Open a listener for the second tun0 to connect to. Then connect to it and send the packets out that connection. Read your data from the listener side.
Open a pipe with two file descriptors. Write to one descriptor and read from the other. Pipes are often used for IPC (Inter-Process Communication) when forking children.
Create a socket and read data from it. Open the other end of the socket for writing. Sockets are often used to allow other processes to communicate with a process. This works well when the calling processes may have a different lifetime than the listening process.
Create a buffer or queue in memory to store the data.

Rabbitmq listen to UDP connection

Is there a way to have RabbitMQ listen for UDP connections and put those packets into somesort of default queue which can then be pulled from by a standard client? Would ActiveMQ or ZeroMQ be better for this?
Consider using a simple proxy front for receiving incoming UDP packets and sending them off to RabbitMQ via AMQP. E.g. in Python you can setup a UDP server and then use the AMQP Pika library to speak with your RabbitMQ server.
Cheers!
Someone also built a udp-exchange plugin for rabbitMQ.
I haven't personally used this, but it seems like it would do the job for you without having to write your own udp to amqp forwarder ..
https://github.com/tonyg/udp-exchange
here's the excerpt
Extends RabbitMQ Server with support for a new experimental exchange type, x-udp.
Each created x-udp exchange listens on a specified UDP port for incoming messages, and relays them on to the queues bound to the exchange. It also takes messages published to the exchange and relays them on to a specified IP address and UDP port.

html5 WebSocket

I already have a server with port and want to write a web app to get the information form the port. Will this be possible with WebPorts?
The Client doesn't even need to talk back to the server, which is the whole point of websockets I would imagine, but since I already have the ports setup, I might be easier and cleaner to just connect and get the info without having to refresh.
WebSockets are not intended as clear TCP channels over which other existing protocols can be implemented.
WebSockets are designed to allow messages to be sent between a client and server, where an event is raised each time a message is received.
Hence a WebSocket client cannot simply connect to an existing TCP server - that server also has to speak the WebSocket protocol.
You could of course write a WebSocket-based server that does nothing but act as a proxy to existing network services.
I think you want websockify which is a WebSocket to plain TCP socket bridge/proxy. It also allows sending and receiving of binary data with the older version of the WebSocket protocol which hadn't yet added direct binary data support.
Disclaimer: I created websockify.