I am requesting RefData from Bloomberg API via c#.
I create a list of 912 securities.
But I get the final "RESPONSE" message after only 92.
Why might that be?
Bloomberg will split up responses for large requests so that each PARTIAL_RESPONSE event will contain data for multiple securities. Currently, it looks like each event will contain data for up to 10 securities, but I would not rely on that number staying the same as I seem to remember a few years ago it was 8.
Related
I am trying to build an Android app that interfaces with the ESP32 using BLE. I am using the RxBluetoothKotlin library from Vincent Masselis for the Android side. For the ESP32 side, I am using the default Kolban libraries that are included in the Arduino IDE. My phone is a OnePlus 5T and my ESP32 is a MH ET Live ESP32DevKIT. My Android app can be found here, and my ESP32 program here.
The whole system works pretty much perfectly for me in terms of pure functionality. That is to say, every button does what it's supposed to do, and I get the exact behaviour I had expected to get. However, the communication itself is very slow. Around 200 bytes/second. My test button in the Android app requests a bunch of text data from the ESP32, and displays this in a dialog. It also lists a number which represents the time between request and reception in milliseconds. Using this, I get around 2 seconds for 440 bytes of data. When I send less data, the time decreases approximately linearly with data size. 40 bytes of data will take around 200ms, and 20 bytes or under typically takes less than 100ms.
This seems rather slow to me. From what I understand, I should be able to at least get a few kilobytes per second. I have tried to check the speed using nRF Connect, but I get the same 2 seconds timespan for my data transfer. This suggests that the problem is not in my app, since I also have it with a completely different app. I also put the code in my main loop inside of callbacks instead (which I probably should have done in the first place), but this didn't change things at all. I have tried taking the microcontroller and my phone to a few different locations, hoping to eliminate interference. I have tried to mess with BLEDevice::setPower and BLEDevice::setMTU, as well as setting RxBluetoothGatt.requestMtu(500) on the Android side. Everything so far seems to have had little to no effect. The only thing that did anything, was adding the line "pServer->updatePeerMTU(0,500);" in my loop during the connection phase. This caused the first 23 bytes of data to be repeated whenever I pressed the test button in my app, and made the data transfer take about 3 seconds. If I'm lucky, I can get maybe a bit under 1.8 seconds for 440 bytes, but this is a very small change when I'm expecting an order of magnitude of difference, and might even be down to pure chance rather than anything I did.
Does anyone have an idea of how to increase my transfer speed?
The data transmission speed is mainly influenced by the Bluetooth LE connection interval (between 7.5 ms and 4 seconds) and is negotiated between the master (central unit) and the peripheral device. The master establishes a connection with a parameter set and the peripheral can propose to change this parameter set. In the end, however, the central unit decides which parameter set is to be used.
But the Bluetooth connection interval cannot be changed by an Android applications directly, which normally act as the central role. Instead it can request a connection priority which is known to have an influence on the connection interval.
var xhr = new XMLHttpRequest();
xhr.open('GET', 'https://api.github.com/repos/vuejs/vue/issues');
xhr.send();
with above code, I can receive top 30 issues list of vue project. But if I want to get top 30 issues whose issue number is less then 8000, how can I do it?
in the github v3 api doc,there are just a feature that allow you get issues since a time point.
One way using API V3 would be to traverse through the issues and find those that you want. In any case the call to the Issues API returns issues in descending order of the date of creation. Which means you just need to traverse through the issues to find the ones having issue number lower than 8000.
In the particular case of vuejs/vue; You can increase the number of issues displayed per page to 100 and then find issues having number less than 8000 in the second page :
https://api.github.com/repos/vuejs/vue/issues?per_page=100&page=2
I feel this is a better option than using issue Search API (V3), since you do not have to deal with a very low rate limit of Github Search APIs.
I've never worked with bluetooth before. I have to sends data via BLE and I've found the limit of 20 bytes per chunk.
The sender is an Arduino and the receiver could be both an Android or a Node.js app on a pc.
I have to send 9 values, stored in float values, so 4 bytes * 9 = 36 bytes. I need 2 chunks for all my data via BLE. The receiving part needs both chunks to process them. If some data are lost, I don't care.
I'm not expert in network protocols and I think I have to give each message an incremental timestamp so that the receiver can glue the two chunks with the same timestamp or discard the last one if the new timestamp is higher. But I'm not sure how to do a checksum, if I really need it or not, if I really have to care about it, or if - for a simple beta version of my system - I can ignore all those problems..
Does anyone can give me some advice? Like examples of similar situations handled with BLE communication?
You can get around the size limitation using the "Read Blob Request" of ATT. It allows you to read an attribute and also give an offset. So, you can use it to read the attribute with an offset of 0, if there's more than ATT_MTU bytes than you can request again with the offset at ATT_MTU*1, if there's still more ATT_MTU*2, etc... (You can read it in 3.4.4.5 of the Bluetooth v4.1 specifications; it's in the 4.0 spec too but I don't have that in front of me right now)
If the value changes between request, I'm not sure how you could go about detecting such a change. You could have the attribute send notifications when there's a change to interrupt the process in case the value changes in the middle of reading it.
I have bunch of records in my offcard application and I want to save them all in javacard,
The question is:
What is the best way of transferring data to Java Card?
Should I transfer all data record by record (each one with a APDU) or send all the records in just one APDU?
Of course I know the limitation size of APDU and I'm using extended APDU in order to send all data just in one extended APDU which is more than 255 bytes..
It does not matter much if you send your data in one extended length APDU or one single APDU security wise. It is however much better to send unrelated information using separate APDU's. This would make your application much more modular. Note that if you send related information using separate APDU's, you may need to keep state between those APDU's for validation purposes (e.g. you may have to send either none or all of them, or send the APDU's in specific order).
Furthermore, ISO 7816-4 only defines 2 byte status words to send back to the sender, e.g. 8A80 to indicate any error in the command data. This means that it is impossible to tell from the status word which of the records contains failure information.
Finally, there are certainly still readers and software out there that have issues handling extended length APDU's. So if your software is going to be used by other parties you may want to stick to normal length APDU's.
I would like to know if it is possible to do a full statement (between a date range) through ISO 8583, I have seen ATMs which do full statements and was wondering what method they used. I know balance inquiry and mini statements are possible on a POS devise over 8583.
If it is possible does anyone have an information on the structure of the message, ideally for FLexcube.
we did something similar to that back in 1999 in one of the banks, where we would send the statement data in one of the generic private use fields, where it would allow the format ANS 999
but that means you are either to restrict the data to less than 999 characters, or to split the data on multiple messages. and have a multi legged transaction.
you would have the following flow
Customer request for statement on ATM
ATM sends NDC/D912 message to ATM Switch
ATM Switch look up account number after authenticating the card and forward the request to Core Banking Application
Core banking application would generate the statement and format it according to predesigned template and send the statement data into a generic field (say 72)
ATM Switch collects the data and formats it to NDC or D912 format where the statement data is tagged to statement printer (in NDC it is a field called q and the value should be ‘8’ - Print on statement printer only)
and on the field r place the preformatted data
however, it is not a good practice to do so, since we have faster means to generate a statement and send to email or internet banking. but this is the bank's preference anyways.
It depends upon implementation,
I had implemented NCR central switch, where I incorporate initial checking stuffs in the Central application itself rather than passing everything to Auth Host.
My implementation.
ATM Sends (NCD) the transaction requests based on State Machine setup in ATM to Central Application.
Central does basic checkings such as Validity of BIN (initial 6 digit of card no.) and also checks if the requested amount of cash is available in the ATM etc.
The the Central App sends the packet (ISO8583/BASE24) is sent to the Acquirer for further processing.
Acquires Sends it to CA and then it goes to Issuer for Approval.
Hope this helps.
The mini-statement is not part of ISO 8583 (or MVA). It is usually implemented as a proprietary extension. Hence you need to go to an ATM owned by your bank, or, is part of a consortium of banks that share an ATM infrastructure with your bank.
We implemented mini-statements in our ISO-8583 specification utilizing a $0.00 0200 (DE003 = 91xxxx) message and the statement data coming back from the host on DE125 on both Connex and Base24 and then modified our stateful loads to print the data at the ATM.
Though full statements fell out of use years ago so we removed it to just be mini-statements now utilizing the receipt printer vs. full page statements. There is a limited number of entries and not all host support it but it is used today on NCR & Diebold ATMs. I've personally participated in the testing in getting it to work on Base24 and Postilion.
The mini-statement data we do print is 40 characters per line and prints about 10 transactions I believe.