I have an imap account, (e.g. some#gmail.com) and I know many libraries with which I can connect and replicate messages back to my destination. I want to achieve following,
First time, I want to download all messages (including sent folders), and when I download for the first time, I will save message with ID and UID locally in some database.
Second time, I do not want to query downloaded messages, even though their read/unread status or any flag or deleted flag is changed or they are purged.
Our aim is to download and sync every messages locally, once and only first time.
Now I know little about IMAP message that they have something called ID, UID and MessageID. ID is probably an offset in current folder, UID is numeric id in current account and MessageID is a unique string.
Now I want to know, what search I should use while querying folder, so that messages once downloaded, wont be returned back to me.
I am planning to use http://mailsystem.codeplex.com/ library, and it gives ability to Search with custom string and returns int array.
Assuming I have, a MaxID, and I want to only download messages which has ID or UID greater than MaxID. Which one should I use? UID or ID?
You should use the UID in combination with UIDVALIDITY. Both values are folder specific.
There is an informational RFC that describes how IMAP clients should do synchronization (RFC-4549, section 4.3). The text recommends issuing the following two commands:
tag1 UID FETCH <lastseenuid+1>:* <descriptors>
tag2 UID FETCH 1:<lastseenuid> FLAGS
The first command is used to fetch the required information for all unknown mails (without knowing how many mails there are). The second command is used to synchronize the flags for the already seen mails.
AFAIK this method is widely used. Therefore, many IMAP servers contain optimizations in order to provide this information quickly. Typically, the network bandwidth is the limiting factor.
Related
I know that AAD application ID is unique in one directory (tenant). It is a guid and apparently should be unique in whole world but collisions may be. The question is: does Azure while generation AAD application ID validate whether it is unique across all others directories or not?
If you look at the official document for application property you would know application id is
The unique identifier for the application that is assigned to an
application by Azure AD. Not nullable. Read-only
How Azure Application Id Generated Uniquely:
Application Id (GUID) break down like this:
60 bits of timestamp,
48 bits of computer identifier,
14 bits of uniquifier, and
six bits are fixed
Total of 128 bits.
The goal of this algorithm is to use the combination of time and location (“space-time coordinates” for the relativity geeks out there) as the uniqueness key.
However, there’s a possibility that, for example, two GUIDs are generated in rapid succession from the same machine, so close to each other in time that the timestamp would be the same. That’s where the uniquifier comes in.
When time appears to have stood still (if two requests for a GUID are made in rapid succession) or gone backward (if the system clock is set to a new time earlier than what it was), the uniquifier is incremented so that GUIDs generated from the “second time it was five o’clock” don’t collide with those generated “the first time it was five o’clock”.
Once you see how it all works, it’s clear that you can’t just throw away part of the GUID since all the parts (well, except for the fixed parts) work together to establish the uniqueness. This is how all that works.
Note: Even sometimes network address also considered for GUID.
I'm writing a small app to test out how torrent p2p works and I created a sample torrent and am seeding it from my Deluge client. From my app I'm trying to connect to Deluge and download the file.
The torrent in question is a single-file torrent (file is called A - without any extension), and its data is the ASCII string Test.
Referring to this I was able to submit the initial handshake and also get a valid response back.
Immediately afterwards Deluge is sending even more data. From the 5th byte it would seem like it is a bitfield message, but I'm not sure what to make of it. I read that torrent clients may send a mixture of Bitfield and Have messages to show which parts of the torrent they possess. (My client isn't sending any bitfield, since it is assuming not to have any part of the file in question).
If my understanding is correct, it's stating that the message size is 2: one for identifier + payload. If that's the case why is it sending so much more data, and what's that supposed to be?
Same thing happens after my app sends an interested command. Deluge responds with a 1-byte message of unchoke (but then again appends more data).
And finally when it actually submits the piece, I'm not sure what to make of the data. The first underlined byte is 84 which corresponds to the letter T, as expected, but I cannot make much more sense of the rest of the data.
Note that the link in question does not really specify how the clients should supply messages in order once the initial handshake is completed. I just assumed to send interested and request based on what seemed to make sense to me, but I might be completely off.
I don't think Deluge is sending the additional bytes you're seeing.
If you look at them, you'll notice that all of the extra bytes are bytes that already existed in the handshake message, which should have been the longest message you received so far.
I think you're reading new messages into the same buffer, without zeroing it out or anything, so you're seeing bytes from earlier messages again, following the bytes of the latest message you read.
Consider checking if the network API you're using has a way to check the number of bytes actually received, and only look at that slice of the buffer, not the entire thing.
A socketIO handshake looks something like this :
http://localhost:3000/socket.io/?EIO=3&transport=polling&t=M5eHk0h
What is the t parameter? Can't find a explanation.
This is the timestampParam from engine.io-client. Its value is a Unique ID generated using the npm package yeast.
This is referenced in the API docs under the Socket Constructor Options (docs below). If no value is given to timestampParam when creating a new instance of a Socket, the parameter name is switched to t and assigned a value from yeast(). You can see this in the source for on Line 223 of lib/transports/polling.js
Socket constructor() Options
timestampParam (String): timestamp parameter (t)
To clarify where engine.io-client comes into play, it is a dependency of socket.io-client which, socket.io depends on. engine.io provides the actual communication layer implementation which socket.io is built upon. engine.io-client is the client portion of engine.io.
Why does socket.io use t?
As jfriend00 pointed out in the comments, t is used for cache busting. Cache busting, is a technique that prevents the browser from serving a cached resource instead of requesting the resource.
Socket.io implements cache busting with a timestamp parameter in the query string. If you assign timestampParam a value of ts then the key for the timestamp would be ts, it defaults to t if no value is assigned. By assigning this parameter a unique value created with yeast on every poll to the server, Socket.io is able to always retrieve the latest data from the server and circumvent the cache. Since polling transports would not work as expected without cache busting, timestamping is enabled by default and must be explicitly disabled.
AFAIK, the Socket.io server does not utilize the timestamp parameter for anything other than cache busting.
More about yeast()
yeast() guarantees a compressed unique ID specifically for cache busting. The README gives us some more detailed information on how yeast() works.
Yeast is a unique id generator. It has been primarily designed to generate a unique id which can be used for cache busting. A common practice for this is to use a timestamp, but there are couple of downsides when using timestamps.
The timestamp is already 13 chars long. This might not matter for 1 request but if you make hundreds of them this quickly adds up in bandwidth and processing time.
It's not unique enough. If you generate two stamps right after each other, they would be identical because the timing accuracy is limited to milliseconds.
Yeast solves both of these issues by:
Compressing the generated timestamp using a custom encode() function that returns a string representation of the number.
Seeding the id in case of collision (when the id is identical to the previous one).
To keep the strings unique it will use the . char to separate the generated stamp from the seed.
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.