I know that the FIX protocol specifies user defined fields that cover the range 5000 to 9999. The same specification says, that you can use the tags 20000 to 39999 bilaterally between parties.
In December 2009 the Global Technical Committee Governance Board approved the use of tag numbers in the 20000 to 39999 range for use as user defined tags to be used bilaterally between parties.
But tags between 10000 and 19999 are also used - for example Trading Technologies uses tag 18214 as IncludeNumberOfOrders in MarketDataRequest (V).
Can somebody explain the usage of tags 10000 to 19999 and give an overview to the current tag ranges of the FIX protocol specification?
Tag numbers from 10000 to 19999 are also user defined but should only be used internally, i.e. actually you should not talk to counterparties using these tag numbers. But if for example you have intra-firm FIX connections you could use these tag numbers to convey information.
The tag numbers greater than or equal to 10000 have been reserved for
internal use (within a single firm) and do not need to be
registered/reserved via the FIX website.
Source: FIX Protocol website: user-defined fields
Edit: so if TradingTechnologies uses a tag between 10000 and 19999 for external communication it is actually discouraged.
Related
A page in author with UUID(jcr:uuid) is activated and its content is replicated onto the 3 associated publish servers.
The content available in all the 3 publish servers has different UUIDs. So, considering the same content across all the 4 instances on AEM (1 author + 3 publish), how to associate with something unique?
I'm implementing a solution where I need to associate a unique id that can be mapped to the individual content across all the instances.
Approaches that I've tried till now:
Used the content path - to generate a unique id - by removing the '/' & '-' in the path.
The issue faced - For some paths this can be more than 128 chars which is the limit for the service to accept a unique id.
If I generate a unique id programmatically it will work, but how can I try to use that to track the back content? As I cannot store this programmatically created id on the jcr:content and activate the page.
Issues - If I replicate the page, it will change the activation date as well- which is also important metadata for the content.
What can be the most feasible solution for the use case? Kindly help with suggestions and possible solutions.
You could use a hash of the content path. Easiest way to get a hash is using hashCode(). For compactness, use the Base64 representation of the hash bytes and truncate after a predetermined number of chars.
I was reading through LTE specifications in order to understand the number of bearers that could be created per UE.
Spec 23.203 - Table 6.1.7: Standardized QCI characteristics, defines 9 values for QoS(Quality of Service) based on performance characteristics of IP packets while according to Spec 24.007 - Table 11.5: EPS bearer identity, E-RAB IDs 5-15(11 bearer IDs) are usable.
I am unable to comprehend whether the number of bearers can be 9 or 11?
Thanks!
It is possible for 2 EPS bearers to have to the same QCI. For example, they could be flowing to different PGWs, but have the same QCI. Hence based on the number of identifiers available, the answer is 11.
QCI 1 to 9 are pre-defined settings and given by 3GPP for every operator and network vendors. This allows for interoperability among vendors.
However, operators can create their own QCI from 10 to 255 with their own customized settings for a particular service (like maximum allowed delay, priority, GBR or Non-GBR, etc.
It's worth noting that is very unlikely that a mobile will use that number of bearers at the same time. Typically you have just one (QCI 9) for pretty much everything you do (including Skype, WhatsApp call or streaming).
If on the top of that you also have voice over LTE, then you get QCI 1 while you're in a call and QCI 5 for IMS signaling.
Cheers
LTE QOS de nes priorities for certain customers or services during congestion. In LTE Broadband Network QoS is implemented between CPE and PDN Gateway and is applied to a set of bearers. 'Bearer' is basically a virtual concept and is a set of network con guration to provide special treatment to set of tra c e.g. VoIP packets are prioritized by network compared to web browser tra c. In LTE, QoS is applied on Radio bearer, S1 bearer and S5/S8 bearer, collectively called as EPS bearer as shown in gure below
for more enter link description here
The operation bellow retrieve of all books only the ones that are into the request. It is clearly a GET operation.
From your perspective what is better ( pro/cons ) of doing those two bellow:
Note:
GET - api/library/2/books/
Retrieves all the books from the Library 2.
Using GET:
GET - api/library/2/books/3/5/10/33/...../pages
Using POST:
POST - api/library/2/books/pages
Body:
{
"books_id": [
2,
30,
40,
20,
30
]
}
I’m in a real doubt here between using POST or GET methods to implement that. Books Ids on URL will get really messy if there was like 100-200 books to retrieve. I want some enlightenment here.
I'm using PHP to handle the Rest Application and all those methods above are valid.
This operation matches the standard semantics of the GET method, and therefore the expectations of various software. For example:
many HTTP clients know that they can automatically retry GET requests in case of errors
it’s easier to cache responses to GET
If your book IDs are independent from library IDs, then it may be better to drop the reference to the library, and do just
GET /api/books/3,5,10,33/pages
Books Ids on URL will get really messy if there was like 100-200 books to retrieve
If every book ID is 6 digits long, this adds up to just 700-1400 bytes. This is well within the range supported by any good HTTP client. To really push the practical limits on URL length, you would need many more books — but do you really need (or want) to support retrieval of so many pages at once?
(Alternatively, though, your book IDs might be much longer — perhaps UUIDs.)
If you do run into limits on URL length, it’s OK to use POST to a dedicated “endpoint”:
POST /api/books/bulk-pages
{"books_id": [3, 5, 10, 33]}
POST is defined in RFC 7231 § 4.3.3 as a sort of “catch-all” method:
process the
representation enclosed in the request according to the resource's
own specific semantics. For example, POST is used for the following
functions (among others):
o Providing a block of data, such as the fields entered into an HTML
form, to a data-handling process;
As a curiosity, there has been a recent attempt to standardize a SEARCH method that would allow request payloads like POST, but also be safe and idempotent like GET. Unfortunately, that effort has stalled, so you probably shouldn’t try to use SEARCH now.
Technically, the protocol allows you to send a payload even with a GET request, but as RFC 7231 § 4.3.1 notes, this is unusual and may cause trouble:
A payload within a GET request message has no defined semantics;
sending a payload body on a GET request might cause some existing
implementations to reject the request.
Query parameters
For retrieving multiple books, consider query parameters (using ?):
GET /api/library/2/books?id=3,5,10,33
Matrix parameters
For retrieving pages of multiple books, you could consider matrix parameters (using ;):
GET /api/library/2/books;id=3,5,10,33/pages
Then you also can use query parameters to filter the pages.
• For more details about matrix and query parameters, refer to this question.
• Also refer to the following sections of the RFC 3986 for more details: §3.3 Path and §3.4 Query
POST in your case does not look semantically correct. Maybe you can try query params like
GET - api/library/2/books/pages?ids=[1,2,3,4,5]
I would like to use the Github API to retrieve the number of repositories for each language. For example,
C++ 200,134
Java 175,432
C# 123,453
...
The only API with a filter parameter would by the search repositories one:
GET /legacy/repos/search/:keyword
with the optional parameter language.
But that would returned a list of repositories on multiple page, so you would still need to make the sum yourself.
Note that very recently (as in early March, 2013), the API might limit the result to 1000 results only.
Following up on VonC's answer, the search API will now give you the total number of results matched by your query. So you can use this to get the total number of repositories for one particular language:
GET /search/repositories?q=language:languagename
Language name is case-insentitive, must be URL-encoded, and spaces must be replaced with dashes. For example (Objective C++):
GET /search/repositories?q=language:objective-c%2B%2B
{
"total_count": 2090,
...
I am developing a SIP client. I understand SIP requests and SIP responses but, in SIP messages, how are the call id and branch tags generated? RFC3261 does not specify this.
The Call-ID header value can be anything you want but does need to be unique in order to avoid requests getting classified as duplicates.
THe branch parameter on a Via header needs to start with the magic cookie value of z9hG4bK and must also be unique to avoid the request getting classified as a duplicate. For SIP Proxy's wanting to do loop detection there is also the guideline in the RFC in section 16.6 point 8 which details factors to take when constructing the branch parameter value.
Your wording is difficult to understand. I'm going to assume you want to know how a UAC should generate a Call-ID or how a UAC or proxy server should generate a branch parameter.
The only requirement for Call-ID is that it should be unique. It is often in the form of a unique token + "#" + a host name like email's Message-ID, but it doesn't have to be. It can be just a unique token. The unique token can be anything that is reasonably certain to be unique. In order to avoid divulging private information you can just make it pseudorandom or a cryptographic hash of private unique information (time, process ID, etc...)
Similarily, the branch parameter is just a unique token, but note that it has to start with z9hG4bK as specified in the RFC.
Why re-invent the wheel?
There are open source SIP projects and their implementation may inspire you.
You didn't mention what programming language you use. So I assume you can read C code.
Get the source code of kamailio server. The implementation of Call-ID is in kamailio-4.0.x/modules/tm/callid.c. I believe you are smart and can find out about branch tags yourself :o)