I am a newbie to SDN and have to implement latency monitor with Ryu controller.
I am thinking of sending a packet from switch to switch, where i remember the packet send, and then i recieve it at end switch i will calculate the delay.
The problem is i dont know how to tell apart the packets, which i send. I was thinking of putting into them a string which would tell me:"hey i am packet number 23." But i dont know if it is possible. I read the ryu wiki several times and looked over the examples.
I just dont know how to move forward.
I have answered a similar question over here about how to measure latency. You can have a look. But if you wanna go ahead with your current approach. You can try something like this:
Record switch details and current timing value in packet and send the packet to next switch (via the link for which you want to measure latency).
When recieved that packet on another switch parse the recorded information.
Subtract the timing delay.
For example you can have a look at RYU implementation at here which uses a kind of similar mechanism to discover topology. LLDP packets are generated by controller, sent to one switch which is to be forwarded via a specific port, when another switch receives this packet, it parses the packet to obtain sender switch's id and port and again sends this information to controller, which in-turn detects that there is a path between these switches.
But I would suggest you to have a look at the papers I mentioned before implementing your approach (if at all you have not already done the hard work).
Related
So I am asking this question for my sysadmin. We have a rather large print server, with over 250 copiers. Currently, to adjust configuration we have to use a web GUI and go through a bunch of clicks per IP address. With 250+ copiers, this is very time consuming. We are looking for a way to bulk configure these copiers by executing a process. I have captured the packet that adjusts the setting on the copier. I was hoping there might be someone out there who knows if it is possible to take this HTTP packet and somehow transmit this packet to all copiers with the press of a button, and automating the whole process. I have very light knowledge of packets and the protocols associated with them, but if someone has the knowledge, I would love to pick your brain...
I am in a process of learning and trying to use the RTP/RTCP protocol. My situation is that there is 1 to n streamers and 1 (or potentially 1 to m if needed) receiver(s), but in a way that the streamers themselves do not know about each other (they cannot directly due to technical reasons, such as different network, limited bandwidth, etc...). So it is more like multiple unicast sessions, but the receiver actually knows about them all, collects data from all of them, it is just the senders do not know about each other .
Now reading about the protocol, it seems to me that huge portion of it is related to sending some feedback, collision detections, and so on. So I have doubts, is RTP is really applicable in this case? Is is already used in this way somewhere?
Seems to me it is still beneficial to collect statistic about data transfer that RTP provides (data sent, loss, times, etc...), it just feels the most of the protocol is sort of left out...
Also I have one additional question, going through the various RTP libraries, they all assume that sender will also open ports for receiving RTP/RTCP data, does RTP forbid use of one way communication? I mean application that would only stream the data, not expecting to receive anything back. The libraries (e.g. ccRTP) seem to assume both way communication only...
RTCP is the protocol that provides statistics. The stream receiver (client) will send stats to the sender (server) via RTCP. I don't believe the client will get any statistic reports from the server.
There's nothing wrong with a single client receiving multiple unicast sessions from various servers.
RTP requires two way communication during the setup process. Once setup is complete and the play cmd is sent, it is mostly one way. The exception are the "keep alive" packets that must be sent to the server periodically (usually every 60 seconds or so) to keep the stream going. The exact timeout value is sent to the client during the setup process.
But if you implement your own RTP, there's nothing stopping you from having the server send the stream continuously without any feedback from the client. Basically it would be implementing an infinite timeout value.
You can read about all the details in the spec: RTP: A Transport Protocol for Real-Time Applications
I have a set up that involves exactly one client and one server. The client can generate 32K data really fast. As I generate that data I'd like to send it in parallel over TCP to the server and have it reassembled in the same order that I sent it out in.
So I have the thought where I add each 32K packet to a queue on the client, then something sends out those packets in parallel. On the server, those packets are received in some random order, but then put back in order into a queue and then I can simple dequeue the packets. I have a picture of this set up:
Does this set up have a name? Fanout/fanin? What should I be searching for? It seems middleware such as ZeroMQ might help, but I haven't been able to see any specific examples that display this type of architecture.
I assume this is a solved problem with some nice open source libraries out there, but my assumptions have been wrong in the past.
Thanks for any help.
IS there a way I can in user-space get notification about a packet being dropped at Layer-2 in 802.11.
According to my understanding what happens is, when a packet is sent out on the medium, there are Layer-2 ACKs which are received if it is delivered correctly (if not,it does the retransmission and ultimately drops the packet if not delivered after several retries..)
I want to be able to access this notification (in user-space)and change the behavior of packet transmission.
I want to be able to send the packet to another host from the FIB rather than dropping the packet.
I have read about libpcap libraries and netfilter hooks which allows me to capture packet and inject them back on the networking stack..
But I'm not able to find hooks (if any, for the wireless stack) to help me capture the packet notification in Layer-2.
Please correct me if I'm not understanding something correctly. Also, any heads-up or links to read would be great.
No, you cannot, at least not using the standardised sockets interfaces. 802.11 is a link layer, and the sockets API is strictly link-layer agnostic: unless it's going to work on all link layers, it's not in sockets. There are good reasons for that: the kind of cross-layer interaction that you envision has been tried many times, and it's always turned out more trouble than it's worth.
You didn't give us any details about the application — but the best solution is most probably to change your application-layer protocol to send explicit acknowledgments, and send your data over the fallback route when you fail to receive an ACK.
we're going to develop a game with internet multiplayer support. since it's an interactive game I know I have to use UDP to reduce connection latency, but I'm wondering what are the possible errors that may occur in a package delivered using UDP connection? everywhere I looked they say UDP provides "Best effort delivery", but no one does give a complete explanation what does it mean. after reading some article there are two questions that I still have:
Is it possible to send a package and receive part of it at the other end of connection?
if your answer to first quesiton is true what would happen to the next packages? should I wait for the rest of package or can I assume next package start with my next recv call?
for our game I think we will need to send 4 packages of around 20 byte each second.
The most common thing that can happen is: one side sends a message, the other receives nothing.
Is it possible to send a package and receive part of it at the other
end of connection?
Not really, not even when the message is huge and it gets fragmented. Unlike in TCP, in UDP every message is independent. You either get it entirely or nothing at all.
So what you should do it just recvfrom things in a loop and process them. Obviously you should make your application impervious to message loss such that a missing message doesn't crash it.