I am doing my project in USB.For that I need to know about End point Mapping in USB.Ingeneral End point is Buffer for storing information from the usb device before it send it via pipe to the host.so what is end point mapping??what is the Importance of end point mapping?
The Source Doesn't contains the answer for the question what i am asking.It just gave plain information about how we able to get descriptors from USB Device.My intension is,suppose the device supports Multiple Interfaces,Each interfaces we assigned end points,How to avoid the same end point address or index again used in other interfaces?For that How to we write program for automatically detect The partcular end point address is already assigned?
Each endpoint, in an interface, describes a single stream of input or output for the device. A device that supports streams for different kinds of functions has multiple interfaces. A device that supports several streams that pertain to a function can support multiple endpoints on a single interface.
All types of endpoints (except the default endpoint) must provide endpoint descriptors so that the host can get information about endpoint. An endpoint descriptor includes information, such as its address, type, direction, and the amount of data the endpoint can handle. The data transfers to the endpoint are based on that information.
Source
Related
In SysML, when modeling a message, I'm having trouble understanding what element type should be used to define it, its elements, and a port that it flows through.
I'm assuming it is either:
a raw Block
the more specialized InterfaceBlock
Both can type a proxy port (formerly flow port, if I understand correctly), or type most other properties in other blocks as one builds up a full message interface or port system (either straight ports or nested ports). If the base message definition is a normal block, then when do you create a flow property that gets typed by that block, so that something can actually flow from one task to another through the port?
An Interface Block should occur somewhere in there, in order to type the port, right? Does that mean I use it to define a message directly, or does that depend on my port scheme (i.e. whether I nest ports and to what level)?
I guess this boils down to confusion over when you are defining a thing (i.e. a class/block) and when you are defining that this thing is a quantity that flows in your model (a flow of some kind - the message passes from one task or piece of hardware to another).
P.S. I'm using MagicDraw as the SysML tool, but I don't think that should impact the core answer.
The answer, as developed by my team:
Use a full port for the raw network interface, the physical layer.
Use a block to type the network interface, including:
Flow properties that represent physical items flowing out of the port, such as total electrical current (power).
Nested full port elements for physical nested ports, such as pins that make up a physical ethernet port. Type with another block.
Nested <> elements for logical/abstract data flows across the network interface, such as sockets/connections
Use an Interface Block to type each logical connection (nested proxy port) with an Interface Block containing the following:
Flow properties that represent blocks of data, such as messages, which are sent as a group across the connection
Value properties that define characteristics of that connection, such as source and destination IP addresses and port numbers, comm loss and retry info, etc. Note some of this may be better served as meta data in tags as part of a separate stereotype.
Type the data flow properties of the connections with a ValueType whose attributes are the individual data elements of that data block (i.e. the message elements).
Create a new stereotype with a custom name something like "Data Element" and add tags for any meta-data that is needed about each data element, such as length (in bits or bytes), underlying type in the message, any unit or scaling factors, position in the message, etc.
You can even create a generic table at this point which will list every data element in a given message, or in all messages, and add all the relevant Data Element tags as columns, and use it as a current specification for each message and data element of each message, and allow much easier editing of all the information directly in that table.
Why use ValueTypes for data blocks that flow across Proxy Ports? Because then they will show up as Information Flow items instead of Item Flow items across a connector between two Proxy Ports on an Internal Block Diagram (IBD). I.e. when I send a physical item, typed by a Block, it is sent as an Item Flow, but when I send a logical item, such as data, it is typed by a ValueType, and sent as an Information Flow.
This is a starting point - we found issues with nesting the valuetype definitions initially, so opted for a much flatter message definition that contained all the aspects of a message in a single ValueType, rather than nesting them. I'm sure there are ways around this, but how complicated do you want to get?
When is an API NOT RPC ?
After a long long discussion on twitter regarding API design.
I want to try to come to a clear answer when an API is not RPC based.
There seems to be quite a bit of confusion around this Is That REST API Really RPC? Roy Fielding Seems to Think So
That specific link is about REST and RPC. my question just aims to ask about RPC vs not RPC in general, not in the context of HTTP.
The TLDR; definition of when an API IS RPC is "when it hides the network from the developer"
Fair enough.
But back to when is it not.
The Twitter duscussion focused on the HttpClient, as not being RPC.
My argument is that the HttpClient does not really model the network.
There is nothing in there modelling latency.
There is also a very weak representation of network failures.
Most status codes in HTTP are not network related, e.g. NotFound, Payment Required etc.
Depending on language and SDK, the HttpClient may take a string or an URI.
In the case where it takes a string representing the URI, that also doesn't really communicate that there is a network involved, you would need to know what the string represents and whant an URI is.
If you had never seen HTTP before, how would you know by looking at that specific API?
There is an API consuming a string, and returning an object either containing a string or some int response codes.
How would you know?
Most developers of-course knows what HTTP is, but from a strict definition point of view, how would you define an API as not RPC?
Would a checked exception in Java "NetworkException" be enough to clearly communicate that there is a network involved?
If the functions you are calling have descriptive names like "SayHelloOverNetwork" would that be enough to make it not RPC?
And exactly when is a procedure a procedure in remote terms?
All network communication will result in some code being run on the receiving system.
If we take a person who have never been in touch with technology or protocols, and teach this person a programming language.
What would be the definition of "Not RPC" this person could employ to spot what is RPC and not?
I am being dense and possibly silly here, but I am trying to find the essence of "Not RPC", what exactly is required for this?
Does it for example need to be non blocking in order to play nice with unknown latency?
Or could a non RPC API be blocking?
IMO, if it is blocking, it hides that there will be latency involved, and thus falls into the "Latency is zero" fallacy, meaning it hides the network.
This all seems to be super obvious to everyone else but me, but no one have yet shown a concise answer on what the requirements for not being RPC is.
For me it looks like you're putting all eggs into one basket. Lets start from the very beginning:
API is application programming interface
it is a set of clearly defined methods of communication between various software components
The only definitive property of API is that it is defined/documented way of communication.
If one application/module/component A can use/call another application/module/component B somehow - it means that B provides API and A uses this API.
Usually there are two aspects of API which must be defined:
What exactly is passed into/returned from component (its your application logic)
How exactly data is transferred/serialized (this is technical implementation)
I'm not touching "what" part for obvious reasons.
Lets focus on different ways of "how":
push 4 byte integer to stack, change IP register and read 4 byte integer output from EAX register
connect to socket, write data serialized as byte array and read some response as byte array back
call 911 from any phone, say your address and expect several cars on your driveway
In all these cases you're using some API = you're communicating with other components in some predefined way.
RPC is remote procedure call
computer program causes a procedure (subroutine) to execute in another address space
The only definitive property of RPC is that data is passed across different/remote address spaces, some architecture allow different address spaces on single host, for example x86. As soon as different physical hosts usually do not share address space, any call across network is RPC, but not vice versa.
Note: It is rare, but possible to share memory space across different physical hosts connected in network - then such communication strictly speaking is not RPC, lets omit such cases.
Any RPC call automatically means that you're calling some API. By definition. So we can say that RPC is part of API's "how", it is transport level. As soon as RPC itself does not define actual mechanism, there are could be very different implementations, for example shared memory, DMA, TCP/IP, etc.
I suppose now you can answer your question when an API is not RPC based - When API says so. It is up to API developer to define whether it should/can be called via RPC or not, API can define multiple ways of calling it.
As antonym to RPC you can use "in-process".
So, phrase API IS RPC is "when it hides the network from the developer" is absolutely non-sense. API must define "how" section.
HTTP is hyper text transfer protocol
request–response protocol in the client–server computing model
The only definitive property of HTTP is that it describes protocol/format of request (input arguments) and response.
You can use HTTP in non-RPC API. For example I prefer to think about HTTP as file format. So we can say that HTTP is another part of API's "how". It defines serialization part of API, but does not dictate you transport level.
Note: Some RPC protocols actually define both transport and serialization.
So, HttpClient is the tool which allows you to invoke API and use HTTP encoded request/response, usually such library supposes RPC as transport level. None of these terms mandates network or any particular transport protocol. This is why http client should not declare any kind of network exceptions/errors, but it could throw HTTP errors as exceptions.
Note: Network exceptions could be thrown from TCP/IP RPC implementation for example, HTTP client library could proxy them to you. Unfortunately some libraries wrongly couple HTTP with TCP/IP too much and border between different responsibilities is crossed.
REST is representational state transfer
architectural style for distributed hypermedia systems
It is very wide term, it defines a lot of things from different aspects and at very different levels, most important:
HOW your API should be designed (usage of URI)
HOW your API should be implemented (stateless, HTTP verbs)
HOW your API should be called (client-server)
Client-server, usually assumes cross-process communication. Ie different address spaces, this is why we can say that REST mandates RPC as invoking mechanism to API + HTTP as serialization format.
Now, I suppose you will be able to understand these answers:
How would you know?
when you give client your REST API, it automatically defines some part of your API in terms of other protocols. Ie - to use REST API you must read/know HTTP protocol first. API must define what kind of RPC must be used.
HttpClient does not really model the network.
It should not do this. It works with HTTP semantics.
you would need to know what the string represents and whant an URI
There are two URIs actually:
URI is part of API's "What" section, it defines business object location. It has nothing to do with network or DNS system. You should not understand it.
URI could be part of TCP/IP RPC requirements, in this case it represents domain name/path. But some implementations can work with IP addresses, not URI.
If the functions you are calling have descriptive names like "SayHelloOverNetwork" would that be enough to make it not RPC?
As I wrote before - we can assume network as RPC always.
Does it for example need to be non blocking in order to play nice with unknown latency?
Its up to API developer:
API can contain functions which suppose asynchronous execution, but client can call them in blocking way
API can contain blocking functions, but client can call them asynchronously
An RPC is a network API with enough layers of abstraction on top. What's enough layers? That's a subjective thing.
Whether an API is an RPC or not doesn't, in my opinion, depend on method names or the names of exceptions/errors you need to handle. We're adults, we know that the call is done over the network. Naming it "SayHello" instead of "SayHelloOverNetwork" doesn't make a difference.
What does make a difference is all of those layers of abstraction - the less resource management and error handling you need to do, the more RPC-ish the code.
And about the specific HttpClient example - I'd say that today, developers doing high-level work consider HTTP to be a transport medium; an alternative to "plain old sockets".
So while a person who does not know what HTTP is might look at "a function that takes a string and returns an error code" as RPC, a modern developer would probably see it as "nitty gritty networking code". He would then say yuck, and put a few more layers of abstraction on top to make method calls from his business logic more RPC-ish. That way, the business logic would have to handle only the most extreme failures.
A) If the documentation told you how to do what you want by calling the API, then you are calling an RPC-like API, not a REST API.
B) If the API itself told you how to call it to accomplish what you want, then that API is not very RPC-like, and might be a REST API.
Programming in an object oriented or a procedural style is like case (A) -- you know what to call and how to call it to accomplish what you want before you write the code to call it. When [I assume Roy F.] says that an RPC-like API hides the network from the developer, he means that the developer can continue to program in this way whether or not his calls are remote -- he doesn't have to care about the network.
When you call a REST API, however, you have to program differently, because you have to let the API tell you what you can do and how you can do it. That's what it means to be "hypertext-driven".
Being hypertext-driven means that your stuff will continue to work when the guy on the other side of the network, who doesn't know or care about your program at all, completely changes what you can do and how you have to do it. Note that the lack of any contract between you and the system you are calling is the fundamental feature of the network that RPC hides.
I learned on OSDev wiki that Endpoint 0 is the default control pipe, allowing for bi-directional control transfers. This is used for device configuration, e.g. to retrieve device descriptors. The USB 2.0 spec explains this more thorougly in section 5.5 Control Transfers.
There are also a limited amount of endpoints available (2 for low-speed, 15 for full- and high-speed devices). Somewhere in the USB 2.0 spec, I have read that there must be at least one control pipe. This implies that there may be multiple control endpoints, but what is the use of it? Do you know any particular USB device or class that has an EP configured as control pipe?
Later, I found this in the spec, section 10.1.2 Control Mechanisms:
A particular USB device may allow the use of additional message pipes
to transfer device-specific control information. These pipes use the
same communications protocol as the default pipe, but the information
transferred is specific to the USB device and is not standardized by
the USB Specification.
If I understand it correctly, this means that non-EP0 cannot be used to configure the device (say, a standard request such as GET_DESCRIPTOR). But the setup/data/status stages seem still to be available ("[..] use the same communications protocol [..]"). Is this correct? Or is the use of standard/class requests forbidden for non-EP0?
Background: while working on an emulated USB device in QEMU, the need for a USB monitor for debugging purposes appeared. During inspection of the QEMU core USB code, I noticed that it only processed control commands for EP0. Other endpoints would be treated as data. There are some virtual devices (host-libusb) that always reject control transfers for those other endpoints. Hence the question whether this is the correct behavior or not (and if valid, whether there exist devices that really implement this).
As far as I can tell, there is no use for a non-EP0 control endpoint. I have developed several products that use custom control transfers on endpoint 0 as the main way to send device-specific requests and I have not encountered any fundamental problems with doing that.
If you did make a non-EP0 control endpoint I think your understanding is correct; you wouldn't be able to use it for standard requests but you would be able to use it for custom requests and the transaction sequences would be the same as on EP0.
hi guys i'm making a client-server software and this is my first question
i'd like to ask: how to distinguish data that sended by tcp Connection?
Well, my points are:
-we can determine data that sended by tcpconnection.
for example, we have 3 Listviews in our form
the point of the first listview is for Biodata of client.
the point of second listview is for *The value obtained from the clients
n the point of third listview is for The picture obtained from the clients
in this case we have 3 main points that must be processed.
in fact, we only have 1 connection in our system.
Well, here I'm confused..
how to determine that data we received is for the first listview or second listview or third listview?
remember, the data of third listview is a picture that we received from tcpconnection
How do we do that with 1 connection in our system?
do i have to make 3 connection to control third listviews?
With socket communication, both the client and the server must use the same agreed-upon protocol so that they can understand each other. There are many standard protocols that have already been created, so for most tasks, creating your own protocol is unnecessary. However, if you must, you can always define your own protocol. The nature of your protocol will obviously depend completely on your specific needs, so it would be impossible to tell you what the protocol should be. However, generally speaking, the first thing your protocol must define is how to know where each complete message begins and ends. This is often accomplished by separating each message with a delimiter (e.g. new line, EOF, null). As Francois recommended, you could alternatively specify the length of the message at the beginning of each message. Within each message, you then will need a header section which, among other things, would specify the type (the format) of the data stored in the body of the message.
A simple implementation might be to send each message as a JSON or XML document. Doing so makes it very easy to define and modify the format of the message.
However, unless you really need to, I would recommend using one of the built-in communication frameworks that are provided with .NET. For simple tasks, often a simple asmx web service is sufficient. For more complex tasks, often WCF is a good choice. An asmx web service uses SOAP via HTTP via TCP/IP. WCF uses SOAP, but the lower level connection is configurable so it doesn't have to use TCP/IP, but it can easily do so.
This Question is extension of the following
OpenFlow Rule Metadata
I would like to have this clarified, on my question about Metadata
Let us say, I have an Open Flow rules, as below
Cookie=0x8000001, duration=228925.445s, table=17, n_packets=350, n_bytes=32424, priority=10,metadata=0xc000f30000000000/0xffffff0000000000 actions=goto_table:19
I wanted to understand the following
Do we have certain rule/ Algorithm , to determine these Metadata from a Packet.
because the Packet in OVS is actually switched based on Matching Metadata, Is that correct ?? ( At least according to the above flow rule )
And the Packet itself does not carry the Metadata, then how exactly
the packet hitting a flow matched against the Metadata.
So, If I understood it correctly the Packets those are traversed between the flow-tables, are within the OVS application itself or Handled #OVS Application level, until it had determined Egress Port
So in that Case, the MetaData are handled #OVS-Application level, until the Packets is send via Egress Port.
Is this correct??
Finally which Module in ODL is responsible for determine the Metadata, and I would like to understand from the code how exactly it was done.
The OpenFlow metadata field starts with a value of zero for every packets. Tables can then writes to this field and you can match on it in subsequent tables. It is only used to carry information from one table to the next, as explained in the OpenFlow specifications:
Metadata: a maskable register that is used to carry information from one table to the next.
first of all you can try Ryu instead, its code is more easy to read and understand.
Then, I think metadata/instructions/actions.... these things are belong to the processing of OVS forwarding, but these things needs to attach to something and that is the packet that OVS received. About the question "Do we have certain rule/ Algorithm , to determine these Metadata from a Packet. " I think the value of the Metadata is determind by the controller, which means that it depends on 'how do you design your own network instance using some(e.g. RYU) controller application'.