I wanted to know if anyone has any idea of how I can handle this scenario:
I want to have two terminals open. In one of them I want to run an NS-3 script file which generates packets and sends it through a socket to the other terminal.
The other terminal (which is only running a simple C socket program) receives the packet through the socket (and ideally displays the payload or even simpler increases a packet counter).
Any ideas appreciated...
Yes, you can make ns-3 interact with the real world.
Please read this tutorial :
http://www.nsnam.org/wiki/HOWTO_make_ns-3_interact_with_the_real_world
Especially Tap bridge. The Tap Bridge is designed to integrate “real” internet hosts (or more precisely, hosts that support Tun/Tap devices) into ns-3 simulations
http://www.nsnam.org/docs/release/3.18/models/html/tap.html
Related
I'm currently trying to implement the SOME/IP protocol which uses multicast for the service discovery. The Language is c++ and the asio library (without boost) is used in my case.
Currently the code works, but only on 2 diffrent machines. When i try multicast between the 2 apps on the same host i also receive the messages that i just send out. I understand that this is the purpose of the loopback interface, which is enabled when running on the same host but i'm wondering how you could filter out the own messages that were just send and not receive them again? As implementing the standard with that behaviour on one machine is nearly impossible.
When i bind the one programm to my ethernet interface and the other to my wifi interface a normal connection is possible without receiving the your own messaged again after sending.
Is it normal when you implement a network protocol to have 2 machines for testing or am i missing a simple settings which enables me to send / receive from 2 programms to the same multicast , on the same interface, without receiving its own send messages?
Essentially i want to send / receive with 2 programms on the same interface to the same multicast address without also receiving my own messages in each programm after sending them.
Thanks in advance for the help. If you have further question or if my explanation is not good to understand just ask please
I already tried using diffrent ports on the same machine, which resulted in no receiving of any data.
So I have on one hand an embedded device with a camera running openCV and on the other hand a C++ (Qt) GUI. I would like to connect both i.e.:
"stream" all the output image frames/video from openCV to my remote C++ gui
send commands from my C++ gui to the embedded device
How can I do this, what possibilities do I have? I was thinking about sockets, but I don't know whether that is the easiest solution to stream the image frames from openCV to my Qt gui.
Thank you
You should give us more details about what you're trying to achieve.
You say "stream [...] to my remote C++ GUI": do you mean sending the data over a cabled connection? over a LAN network? over the Internet?
Depending on the answer this changes your system's architecture quite a bit. Especially in case you want to stream the data over the Internet. If your use case implies a LAN network, you can easily setup a peer-to-peer connection between the embedded device and the C++ app to send data. However, it's much more complicated if you want to send data over the Internet, because it is difficult to create a peer-to-peer connection if you don't have static IPs (which I'm assuming you do not have). You will need a server (which can be written with Qt as well) to work as a relay for sending data from the device to your C++ app.
Do you need actual video streaming (at 25fps), or is a low refresh rate (1-0.5fps) sufficient ?
(I'm making the assumption you want to send data over a network)
Because if a low image rate is sufficient, using WebSockets to send images on a regular basis might just do the trick.
Otherwise, you'll need to setup a UDP connection with a video buffer.
Hope this helps!
D
I have written a server and a client both as separate apps. They communicate through UDP Multicast (becouse I need that everyone who joins the group can read & write messages). Now I have two windows, but my aim is to create one simple chat program, but I don't know how to listen and send at the same time. Do I need to create 2 sockets? Or can I use just one? I've even tried to merge both apps in one, but I didn't succeeded (I know, I know.. but I was kinda desperate).
I've searched google for a tut, but didn't succeeded.
I'm using c++.
You can use one or two sockets, it all depends on whether you wish to bind to a particular network adapter and whether you wish to use unicast & broadcast packets. It is often easier to manage one for sending and one for receiving.
To listen to sent multicast packets on the same host check the IP_MULTICAST_LOOP socket option, noting it applies differently on Windows to Unix.
I am currently working on creating a scalable server design in C++ for a ubuntu server. Is piping across a LAN achievable? What is the best option for speedy inter-LAN communication?
Background Info for those interested:
I'm making a multiplayer game with a friend. It's going to be TCP based. The thing is for linux making a server be multi client seems to mean creating a new process per client or select()ing through a fdset of connected clients. I want to combine these approaches and have a "manager" process that will select through maybe 100 clients and report any changes up the chain to a "taskmaster" process which will then distribute the change to the other manager processes. This will work fine with piping if the managers and taskmasters are on the same box, but if I want to scale it later I need a speedy inter-Lan communication method.
Checkout the netcat application. On one machine, you can run netcat as a server, piping the output to your process:
nc -l -p 1234 | myApp
This will listen on TCP port 1234, and print everything it receives out over stdout.
And on a second machine:
myApp | nc 192.168.1.2 1234
Where 192.168.1.2 is the IP address of the first machine. You'll need to look up the nc man page for the specific details - the above is all from memory.
A stream socket (SOCK_STREAM, combined with AF_UNIX if stricly local or AF_INET if over tcp/ip) is the network equivalent of a bidirectional pipe, with all data ordered.
Just the way you are asking that question, you seem to have the perception that for communication between related processes, pipes is the necessary answer.
The way to think about it is that you need communication between two processes, whether they be a couple of components in your system, client server pair, or whatever. Then you pick a mechanism that works for the given geography. Pipes work if the processes are local. You could also use shared memory queues for a no copy channel. You could also use IP (via sockets) over the loopback interface. To go across the network (WAN or LAN) you pretty much have to use IP.
Lastly, in addition to TCP, consider using UDP as well, because you get builtin message boundaries and easier endpoint management.
LANs typically are Ethernet based networks. This means that any protocol running on your network must be Ethernet based. TCP/IP can and does run on Ethernet networks but pipes and Local sockets are only designed to be an inter-process communication on a single host so is totally not suitable for multi-host applications.
If the various components run on different host, you will need to link them via some TCP/IP based protocol. There are some legacy protocols like IPX and UUCP that run over Ethernet but these have been totally superseded by TCP/IP.
I want to play that Qbasic Gorillas game with someone that lives in Florida.
Here's the flash version online
Gorillas
This link is to someone's post about the remake he programmed - there is a link to the game above in there and also his source code for it
playerio.com
If possible, how can I modify the code so that I can play against them over the innernet?
Should the game be public, private, or some combination of both?
It would also be cool if you could replay tosses or entire rounds with their respective angle/velocity inputs.
Take a look at sockets. Sockets are how you can connect two computers over the internet. In most implementations of sockets, you have a server socket and a client socket. The server socket listens for connections, and the client socket tries to connect to a server socket. In your case with just you and your friend, it doesn't matter much which of you is the server or client, but you will have to program for both. You also have to choose a protocol to use. The two protocols for online gaming are TCP and UDP. TCP is the most common and it is a reliable "guaranteed" connection (TCP would send data that is important). UDP is a connectionless protocol where the client just sends data with no guarantee that the data will actually get there. UDP is mostly used for very frequent updates in online games (UDP would most likely be used to send positional data in a first person shooter for example). So with your protocol in mind, I would start by adding a simple chat feature to the game. That way, you can see something working and start to understand what is happening better.
Just to suggest an alternative approach, if you want to play a game that is local multiplayer, you could set up DosBox or a Virtual Machine and then install a VNC server that both of you can log into. This would give you both KVM control.
Since it is a take-your-turn game. you could even use a chat application that has the ability to share keyboard and mouse input.