I have a DUT that can take packets from all 4 identical interfaces (A, B, C, D) Packets from one port can go to either one of the output ports (1,2,3,4). Example: Packets from A can go onto 1, 2, 3 or 4. Packets from port B can go to 1, 2, 3 or 4 and so on. Packets coming on the same port are in order but packets can be serviced in any order between A, B, C, D (no order is maintained between ports since all 4 interfaces can be active at the same time sending packets).
How do I verify such a DUT? What scoreboard data structure to use? I need to treat the DUT as a black box for I do not know how does the DUT decide which port to send the packets on. I have an uvm agent on each of the 4 interfaces A, B, C and D. A virtual sequence controls the sequences on all 4 agents.
Any inputs? Thanks in advance.
Your question is very broad and opinion based. You can only verify based on the requirements that are given to you. A packet that comes in has to come out intact. If there are no requirements about which ports they come through, then it should not matter to your testbench. There must be some other requirements that deal with throughput that you have not mentioned.
In the simplest situation, you need to make all your packets unique with a global packet ID so that you can send them to a common scoreboard, and at the end of the test, match up all the received packets with the sent packets. An associative array with the packed ID works well for this.
Related
I have a scenario which requires the use of a TCP Relay. Before I set out to write something custom, I wanted to see if anyone knows of existing software that can do this for me.
I have 2 devices on separate networks that cannot connect to each other. Let's call them networks A and B. These devices need to communicate, and they can do so via a "middleman" relay on network C. A can connect to C, and B can connect to C. C cannot connect to either A or B.
A -> C <- B
The idea is as follows:
A establishes a TCP connection to C and simply waits
B establishes a TCP connection to C when it wants something from A.
C reads the data from B and responds with it to the already open connection from A.
A processes the data and responds to C, which relays to B.
Is there an existing tool out there that can do this?
As explained here: https://serverfault.com/questions/634516/existing-tcp-relay-solutions/634519
socat TCP4-LISTEN:12345 TCP4-LISTEN:54321
(where 12345 and 54321 are the ports on which the server listens for each connection). One of the clients connects to one port, the other on the other port, and then data is exchanged in both directions. If one machine sends data before the other connects, it is buffered and sent after the connection.
This paragraph if from UNP,
chapter 21.3 page 555
A host running an application that has joined some multicast group whose
corresponding Ethernet address just happens to be one that the interface
receives when it is programmed to receive 01:00:5e:00:01:01 (e.e., the
interface card performs imperfect filtering). This frame will be discarded
either by datalink layer or by the IP layer.
I just don't know which special case is the author talking about. Could you help me explain it clearly?
IN IPV4. A multicast Address (old class D) consists of 4 bits fixed for identifying it as multicast(1110), and the remaining 28 bits to Identify the group.
Since there are only 23 Bits available in a MAC Address (the high order 25 bits are fixed), when you map the lower order 23 bits of the multicast address into the lower order 23 bits of the mac you lose 5 bits of addressing information. So multiple Multicast addresses all have the same MAC address.
for example
237.138.0.1
238.138.0.1
239.138.0.1
all map to MAC address: 01:00:5e:0a:00:01 (There are more, this is just a subset to illustrate)
so if you join group 237.138.0.1, your ethernet card will start sending frames up the stack for that MAC. Since it is an imperfect match (since we discarded those 5 bits), the ethernet card will also send 238.138.0.1 and 239.138.0.1 up the stack as well. But since you are not interested in those frames they will be discard at Layer 2 (data link) or Layer 3 (Network) when they can be matched exactly.
So the special case is that if you have multiple multicast streams that occupy the same lower 23 bits of address space, all hosts on the network segment are going to have to process the packets higher up in the stack and thus do more work to tell if the packet they got is one they are interested in).
normally you just need to make sure when planning your multicast deployments, that you try to avoid overlapping addresses.
If client socket sends:
Packet A - dropped
Packet B
Packet C
Will server socket receive and queue B and C and then when A is received B and C will be passed to the server application immediately? Or B and C will be resent too? Or no packets will be sent at all until A is delivered?
TCP is a sophisticated protocol that changes many parameters depending on the current network state, there are whole books written about the subject. The clearest way to answer your question is to say that TCP generally maintains a given send 'window' size in bytes. This is the amount of data that will be sent until previously sent acknowledgments are successfully returned.
In older TCP specifications a dropped packet within that window would result in a complete resend of data from the dropped packet onwards. To solve this problem as it's obviously a little wasteful, TCP now employs a selective acknowledgment (SACK) option (RFC 2018). This would result in just the lost/corrupted packet being resent.
Back to your example, assuming the window size is large enough to encompass all three packets, and providing you are taking advantage of the latest TCP standard (don't see why you wouldn't), if packet A were dropped only packet A would be resent. If all packets are individually larger than the window then the packets must be sent and acknowledged sequentially.
It depends on the latencies. In general, first A is resent. If the client gets it and already has B and C, it can acknowledge them as well.
If this happens fast enough, B and C won't be resent, or maybe only B.
I'm using VC++ 2010 and Windows 7.
I have two UDP sources and only one receiver. Suppose source1 sends : 1, 3 , 5 and source2 sends 2, 4, 6. I want to receive 1,2,3,4,5,6 in the same function (digit order doesn't matter). Until now, I made 2 sockets listening on 2 different ports to receive data and then combine them.
How can I use a single socket instance to receive UDP traffic from multiple sources?
On a receiver side create a single socket and bind it to some port. Then make both senders specify this port in the destination address calling sendto. This should do the trick.
There are several things you should remember working with UDP. The order in which the datagrams arrive is not specified. You won't know if any of the datagrams is not delivered either. Besides, you might even get duplicate datagrams several times.
I am looking at a blocking call of send() and looking if there is a way to measure the times spent in the function while be able to know what event's occured during that time so that a qualitative analysis can be made about the connection speed etc.
With that, one of the first thing to know is at which layer does the function return success.
The send() API is going to return success nearly immediately IFF there is sufficient buffer space available to hold the data and the routing tables still show a way to route the packet to the peer. (It doesn't actually have to be able to reach the peer -- simply that the machine must have a next hop available...) If it needs to wait for buffer space to free up, it will. (Watching data being ACKed or sent on the wire ought to be easy with Wireshark.)
Incidentally, the OSI layers are imperfectly applied to the TCP/IP family of protocols; layers 1 and 2 fit very closely, layer 3 is roughly IP routing, layer 4 is roughly TCP, UDP, SCTP, ICMP, and so on. But layers 5, 6, 7 don't have real analogs -- SMTP over TLS might be considered a layer 7 or perhaps the SMTP is layer 7 and the TLS is layer 6 ... it all gets pretty fuzzy very quickly.
It's easier to just talk about the specific layer in the TCP/IP protocol stack that you're curious about. send() works with stream, datagram, and raw sockets, so it could straddle multiple layers of the stack -- you could use it to send TCP, UDP, SCTP, or ICMP packets, or scribble directly on the wire if you wish.