Lets say that I have a function todo() and I want to implement this function on a packet sent from a node to a destination among all the routers.
So I want that the packet goes through TCP via ethernet(could be anything) and while going I want to process the packet by calling todo() on it.
I am trying to simulate this on omnet and thus wanted advice on it...
Do i need to implement the entire TCP stack first or is there an inbuilt feature for simulation in it and if there is does it allow me to do the thing I mentioned ??
I am a beginner in using omnet so please provide me with guidelines on how to do this.... Thanks a lot ...
Your question is little confusing.
Routers process IP packets. They dont care about the payload, which might contain a TCP segment.
You have a scenario like this:
Client -> Router -> Server
So the Client will create on L7 a packet and gives it to TCP module. There you can add your function. For example in the sendToIP function
The packet goes to IP and goes out via Ethernet to the Router. Router looks at destination IP address and send it out the interface as configured in routing table.
The server will receive the packet. it goes through its tcp module (their you can also add your todo() function) and gives it to your application module.
Related
I'll start by saying that currently my server identifies based on sender IP, that is the IP of the client.
Now I am programming a game server (just for practice) and this got me thinking how do I uniquely identify a client if they are on the same IP. (Two players open a connection on the same machine / same network so the outward IP is the same).
I've searched for an answer both on google and here and gamedev.net but am unable to find what I am looking for, likely because I do not know the correct terms to query for.
Any guidance on this would be appreciated, especially in regards to efficiency and best practice.
Thanks.
There is no "connection" term in all stuff related to UDP, but it is common that an application that initiates a UDP socket maintains the same source port over the time, so you could identify it by source IP-port.
There is some stuff related to maintain communication between a client inside a NAT router (in NAT-UDP the client is the first host that send a UDP datagram to another host and trigger a new connection tracking entry) and a server.
This "connection tracking" is only for allow traffic from outside to inside, making a "temporal" relationship (with a timeout), that probably will not be used anymore (only once) sometimes.
If the server doesn't use the same destination port in outcoming datagram as source port in incoming one, the router won't send the datagram to the host inside NAT.
Best regards.
First, I want to give thanks for that amazing lib! I love it. A client is connecting himself to a server. The server should save the IP and do stuff with it later on (I really need the IP). I found that answer: http://lists.zeromq.org/pipermail/zeromq-dev/2010-September/006381.html but I don't understand how I get the IP out of the message (a XREP)... I think I am only able to read the ID, but the IP is managed internally by 0MQ. His second solution suggests to send the IP as part of the message, but I don't understand how to get the "public"-IP. I found that post: Get TCP address information in ZeroMQ
is pass bind a service to an ephemeral port, get a full connection endpoint ("tcp://ipaddress:port")
I don't get how this works. Does he mean something like a web-service?
In my opinion, it would be best to get the IP out of 0MQ (it has the IP already). I would even adjust 0MQ for that, if somebody could point to the place where the IP is saved, couldn't find it. The socket types are not that important, at the moment. I would prefer smth REQ-REP like. Thank you!
Summary:
TL;DR answer to your question is: you can't get IP address of the peer that sent a message, using ZeroMQ API.
Explanation:
ZeroMQ does not expose peer IP address because it is irrelevant for the message based communication that ZeroMQ is designed for. When it is possible for ZeroMQ to get IP address of client that is connecting to server (in example using method described here), it is useless. For a longer explanation here is how it works inside ZeroMQ and any other server implementation.
Server side of the connection does not handle connected clients by the means of the hashtable that maps IP to client, but by keeping track of connected "sockets" (socket descriptors) - when a server accepts (using accept()) a connection, it receives from operating system socket descriptor to use to communicate with connected peer. All server has to do is keep that descriptor around to read() from and write() to that client. Another client that connects to server receives another socket descriptor.
To summarize: even if ZeroMQ would be able to provide you with IP of connected peer, you should not depend on it. ZeroMQ hides from you connection management so you can focus on messaging. Connection management includes reconnections, which may result in a change of IP without changing the actual ZeroMQ socket connected on the other side.
So here's an example of why you might want to get the ip address a message was delivered from: we have a server whose job it is to synchronize updates onto occasionally-connected clients (think mobile devices here, though this is an extreme example of a mobile deivce.)
When the mobile unit comes onto the network, it sends a list of it's firmware files to the server via a dealer-router connection. The server has a list of all applicable firmware files; if the client needs an update it will initiate an update via a separate mechanism.
Since the IPs for the devices can (and do) change, we need to know the IP address associated with the mobile device FOR THIS CONNECTION, i.e. right now.
Yes, we absolutely can have the client send it's IP address in the message, but that's a waste of another n bytes of valuable satellite air time, and while not pure evil, is sure annoying. Zmq already has this information, if it didn't have it, it wouldn't be able to generate replies. The address is in the socket data, there's no reason the message couldn't (optionally, for all you guys who use wired networks and think disconnects are the exception) include a reference to the socket structure so you can get the address out of it. Other than pedantic religiosity, which is far too common in zmq.
The way ZeroMQ is designed there's no information provided on the remote IP. As far as I know you have to manage this through your application by sending that information as a message of some sort.
The messages themselves use an IP-agnostic ID which has more to do with the instance of ZeroMQ running than any particular interface. This is because there may be more than one transport method and interface connecting the two instances.
Using C++ I create a single UDP socket, supplying both an IPv4 address and port. I run this on Ubuntu and have both a wlan0 and eth0 interface up and running. Apparently something decides that both interfaces should be used, I appreciate that. Sending and receiving using a different interface does create a kind of a pickle (NAT traversal???) for me though. Using Wireshark I can see packages coming in, but my application does not register them.
To clarify:
I have a tracker which will supply me with a peer. The tracker will also contact that peer to send me a message. In order to overcome NAT traversal issues, I will send a puncture message.
The problem now is that the puncture messages is sent over wlan (I am testing locally with two machines), whereas the messages from the peer are coming in over eth.
So, I think the simplest solution would be to simply use one interface. (Or both one socket)
EDIT:
I will try what is mentioned here on specifying a single interface.
#Barmar, pointed out that UDP sockets may change interface when sendto is called with a destination address that would benefit from it.
I am still fuzzy on the reason for my problem though. Can someone explain why this is an issue in the first place?
EDIT2:
The above mentioned solution of forcing one interface for the socket bind did not work. Apparently the sendto method will choose to ignore this and still go for the other interface if it feels that that will work better.
Does anyone know how to make sure that socket sticks to the interface it was assigned to?
If you need to ensure that UDP replies come from the same address that the request was sent to, the solution is to use multiple sockets. You open one socket for each IP of the server (this may be more than one socket per interface, because of interface aliases), and bind the socket to that IP. Then you use select() or poll() to wait for requests on all sockets at once. When a request comes in on a particular socket, you send the reply out through that same socket, and its source IP will match the original packet's destination.
I want to develop test application (something like IpSec, but much simple) that implement enacapsulating all IP packets of "PC" in some "another packets" with encription. This "another packets" are sent to another computer (smth like "proxy") that unpack original IP packets and send them to their original destination. Then this "proxy" receive packets for "PC" and decript them, incapsulate and send to "PC" and etc. Application must support working with NAT. I know that IPSec with NAT works only using NAT traversal therefore "another packets" will be udp, i.e. I'll encapsulate Ip in UDP with some encription.
I realize that winpcap not really that I need for develop such application.
Can I develop such application without special hardware, using only soft? What kind of tools should I use (maybe I need to write own driver)?
Ok, If you want to encapsulate your data into ip packets, then that is one thing.
here you say you wan t to encapsulate IP packets
considering OSI layers : wiki
As IP packets are layer 2
you wan't to reimplement layer 2.
I think it is something you can only find in drivers, and therefore hard dependent.
I would like to time how quickly the latency is of a system by sending a packet with the same dest IP as the source IP. Is this relatively simple to do?
How would you custom-build the packets?
Would setting the two IP addresses achieve what I am after?
What is the best timing method?
Any tips/ideas at a low/high level would be greatly appreciated. I intend to use C/C++ on Unix with the boost libraries and libpcap.
EDIT: I should add I will be doing this on a home network, behind a router. I presume the packet will go to the router and come straight back if I were to use 192.168.2.1 (local IP of my system) for the source and dest addresses.
You can just try ping to your own IP. this will produce ICMP packets. There are libraries which also allows you to do the same from an application.
If you want to create packets for yourself you can use socket API. Remember, you can send the source IP address and destination IP address as same, but the port number needs to be different.
For timing you need can use gettimeofday function.
EDIT:
you can ping from your C++ program. See: http://verplant.org/liboping/ or check out some other forum. The reason i emphasized on ping is because it returns right back from the network stack. If you send a UDP packet on the other hand, expecting the application to return and echo, then the processing time of the packet on the listening server gets added.
If you ping to local machine ip (or even lo) it returns without going to switch or next hop router. It will respond even if you remove your eth cable or wifi.
What you are trying to do is implemented in NTP daemon with NTP protocol though.
You don't need a custom package for this. Just create a socket connecting to the same ip-address as the server, and start sending packages. Note that these packages will never leave the network stack, so what you will be measuring is basically how quick the system copies data between user-space and kernel-space.
For the timing, you can use the clock function, it's probably the one most widely used for such things.