On reading about usb protocol in
http://www.beyondlogic.org/usbnutshell/usb4.shtml
It is said that interrupt endpoint is unidirectional and periodic.
Yet, I see in the description for IN interrupt endpoint, that host initiate the IN token and then data packet is send from device to host.
"If an interrupt has been queued by the device, the function will send
a data packet containing data relevant to the interrupt when it
receives the IN Token."
So, If the data packet is sent on this IN endpoint from device to host, doesn't it mean that the same endpoint is used both the transmit and receive ?
I believe the terminology "unidirectional" is meant for only data and not for token and handshake packets. So "IN" endpoint is for reading data and "OUT" endpoint is for writing data. That's why its called unidirectional.
But control endpoint is bidirectional because you can read or write data using the control endpoint. Check the standard USB commands like "Get Descriptor" and "Set Descriptor".
Related
I just finished reading sections 1-6.2 of the OpenFlow specification here.
Section 6.1.2 says:
Packet-in events can be configured to buffer packets. For packet-in generated by an output action in
a flow entries or group bucket, it can be specified individually in the output action itself (see 7.2.6.1),
for other packet-in it can be configured in the switch configuration (see 7.3.2). If the packet-in event is
configured to buffer packets and the switch has sufficient memory to buffer them, the packet-in event
contains only some fraction of the packet header and a buffer ID to be used by a controller when it
is ready for the switch to forward the packet. Switches that do not support internal buffering, are
configured to not buffer packets for the packet-in event, or have run out of internal buffering, must
send the full packet to controllers as part of the event. Buffered packets will usually be processed via a
Packet-out or Flow-mod message from a controller, or automatically expired after some time
This makes it sound like for every packet that hits the OpenFlow switch, an asynchronous message must be sent to the controller to make a forwarding decision. However Chapter 5 makes it sound like a switch has a set of OpenFlow flows and at the end of that generates an action set which determines what should be done with a packet and the packet is only forwarded to the controller when there is a flow table miss.
Under what conditions is a packet sent to the controller for a decision? Is it always? Or is it only circumstantial?
Packets will be sent to the OpenFlow controller any time the out port is set to be the controller.
PACKET_IN events occur when a flow wasn't matched on the switch and are then sent to the controller. Otherwise no event is created - the switch simply forwards the packet according to the flow rules and the controller is none the wiser.
Consider section 8.5.3.1 of USB 2.0 specification:
Control write transfers return status information in the data phase of the Status stage transaction.
For control writes, the host sends an IN token to the control pipe to initiate the Status stage. The function
responds with either a handshake or a zero-length data packet to indicate its current status.
In IN transactions handshake is done by host, not device!
Question is: how device can send handshake for an IN transaction?
In IN transactions handshake is done by host, not device!
I believe there is some misunderstanding.
Device sends NAK/STALL during handshake phase of IN transaction(control write) if there is no data packet during status stage.
If there is a data packet from function corresponding to the IN token, the function expects ACK handshake from host after sending the data packet.
Data packets during status stages are Zero Length Packets.
This is the illustration of scenario in the question:
See also link in comments.
When two peers are using WebRTC transmission with TURN as a relay server we've noticed that from time to time the data inside Send Indication or Channel Data is actually a valid STUN Binding Request message (type 0x0001). The other peer responds in the same way with a valid Binding Request Response (type 0x0101). It happens repeatedly during the whole conversation. Both peers are forced to use TURN server. What is the purpose of encapsulating typical STUN message inside data attribute of TURN transmission frame? Is it described in any document?
Here is an example of Channel Data frame:
[0x40,0x00,0x00,0x70,0x00,0x01,0x00,0x5c,0x21,0x12,0xa4,0x42,0x71,0x75,0x6d,0x6a,0x6f,0x66,0x69,0x6f...]
0x40,0x00 - channel number
0x00,0x70 - length of data
0x00,0x01,0x00,0x5c,0x21,0x12... - data, that can be parsed to a Binding Request
This is ICE (described in RFC 5245) connectivity checks running via TURN as well as consent checks described in RFC 7675.
I'm currently studying how USB works. I read, that there are transactions, which are build from smaller pieces - packets. I read about all kinds of packets.
I can't understand one thing. As the book says - every transaction consists of 3 packets: token, data and hanshake.
The way I understand my book is depicted in the schema below.
In my opinion:
I think the first transaction should contain only token IN and data packet, but no hanshake packet (handshake for what?).
I think, that response should only contain ACK hanshake packet (that the data is written properly to the device).
Please, help me understand it in a proper way.
Best regards,
Tom.
A transaction is a series of one or more packets.
A typical IN transaction with no data looks like this:
The host sends an IN token.
The device sends a NAK handshake packet, which means it doesn't have any data to send.
A typical IN transaction with data looks like this:
The host sends an IN token.
The device sends a DATA0 or DATA1 packet with data.
The host sends an ACK handshake.
A typical OUT transaction looks like this:
The host sends an OUT token.
The host sends a DATA0 or DATA1 packet with data.
The device sends a NAK or ACK handshake depending on whether it accepted the data.
Note that I am just talking about full-speed (12 Mbps) USB 2.0 devices, and things can get a bit more complicated for the higher-speed devices.
Note that any of these packets could be lost due to noise issues. The USB specification specifically accounts for this, ensuring that packet loss doesn't result in incorrect operation of the device or host.
I have an application that transmits some data in a loop.
Underlying protocol is UDP on WinSock. If I don't add sleep(1ms) after each transmit operation most of the data is not sent (or wireshark can not capture it) Have you experienced such a behavour that UDP does not handle repetitive sending in a loop ?
Regards
Tugrul
First thing you should check the return values when you send data to check if data is successfully sent or not.
Second thing, This can happen internal buffer of UDP cannot accommodate more data because previous data is yet not transmitted. So the simplest solution is that each time before send the data you should check if your UDP socket is writable or not. You can do it by calling "select" or "poll" on that UDP socket.