I'm currently developing an SNMP application for work. My boss wants me to somehow identify that a completely new cartridge has been installed and that you get a notice when an old one gets placed again in the printer. To do this, I need some kind of unique value that says that either a new or old cartridge has been placed in the printer. Now I can store this unique ID somewhere in a database, that's not a problem, the problem is: how can I tell if a completely new cartridge has been placed? By some kind of serial number?
I need to be able to retrieve this value by SNMP. (Yes, everything works for SNMP, so technically I just need the OID).
AGAIN: THIS IS FOR LEXMARK
The closest I can find to something being unique for a cartridge is an install date...
Any information on this is very helpful.
using the iReasoning MIB-Browser I found out two OIDs that contain Information regarding serial numbers of cartridges:
currentSupplySerialNumber, OID: .1.3.6.1.4.1.641.6.4.4.1.1.6
and
supplyHistorySerialNumber, OID: .1.3.6.1.4.1.641.6.4.4.2.1.6
Don't know if this helps anymore, especially as the question is dated Apr-10 :-)
PS: I used a Lexmark MX511
Related
Is there an option in DynammoDB to store auto incremented ID as primary key in tables? I also need to store the server time in tables as the "created at" fields (eg., user create at). But I don't find any way to get server time from DynamoDB or any other AWS services.
Can you guys help me with,
Working with auto incremented IDs in DyanmoDB tables
Storing server time in tables for "created at" like fields.
Thanks.
Actually, there are very few features in DynamoDB and this is precisely its main strength. Simplicity.
There are no way automatically generate IDs nor UUIDs.
There are no way to auto-generate a date
For the "date" problem, it should be easy to generate it on the client side. May I suggest you to use the ISO 8601 date format ? It's both programmer and computer friendly.
Most of the time, there is a better way than using automatic IDs for Items. This is often a bad habit taken from the SQL or MongoDB world. For instance, an e-mail or a login will make a perfect ID for a user. But I know there are specific cases where IDs might be useful.
In these cases, you need to build your own system. In this SO answer and this article from DynamoDB-Mapper documentation, I explain how to do it. I hope it helps
Rather than working with auto-incremented IDs, consider working with GUIDs. You get higher theoretical throughput and better failure handling, and the only thing you lose is the natural time-order, which is better handled by dates.
Higher throughput because you don't need to ask Dynamo to generate the next available IDs (which would require some resource somewhere obtaining a lock, getting some numbers, and making sure nothing else gets those numbers). Better failure handling comes when you lose your connection to Dynamo (Dynamo goes down, or you are bursty and your application is doing more work than currently provisioned throughput). A write-only application can continue "working" and generating data complete with IDs, queueing it up to be written to dynamo, and never worry about ID collisions.
I've created a small web service just for this purpose. See this blog post, that explains how I'm using stateful.co with DynamoDB in order to simulate auto-increment functionality: http://www.yegor256.com/2014/05/18/cloud-autoincrement-counters.html
Basically, you register an atomic counter at stateful.co and increment it every time you need a new value, through RESTful API.
thank you for taking the time and interest reading this and hopefully helping me out.
I need an unique user identifier for IOS, and what I mean with unique user identifier is a unique string that Apple provides that is unique for user not device, meaning that it will stay the same across devices. I thought about the Apple ID or something like that, but it´s not possible, because Apple does not provide it(at least not that I know of), but I want something similar to that.
It cannot be the UDID, because(besides being deprecated) it´s not persistent across devices. I want this in order to authenticate a user, without the user having to login, or signup. It is possible to do so, because some apps do so. I didn not log in or anything with another device, but it authenticated me. I had thought it was with the Apple ID, but that´s not possible to do.
I checked this answer: iOS unique user identifier. And it seems that it might be the solution, but I don't quite get it, as I don't see how it would be unique to every new user(being able to distinguish between multiple users, and the same user, but on different device).
I really appreciate people reading this and trying to help.
Thank you
PD: I use Titanium´s Appcelerator, not Apple´s IOS SDK or anything like that. But it´s not that important, I just want to get the process to be able to do it with Titanium's Appcelerator
PS: NOTE:
Thank you for answering and so fast!. I have read it many times and I just don't get it. Could you guys help me understand it a little bit better?
The way I understand it is this.
1.-Create an UUID(changes with every installation)
2.-Store it to the Keychain(As far as I know, the values saved on the keychain are local to the device) with a default service(I think Ill put it with the application's id-com.bla.bla-), and also a default account, I think Ill leave it as "users".
This will all be local, so every single installation will do this, with a different UUID for each installation(not necessary every user)
3.-Save the UUID to the NSUserDefaults.
4.-Save the UUID to the Cloud's public data store.(The UUID in the Cloud´s Data Store, Keychain and NSUserDefaults should be the same)
So, if 5 installations are run, the Cloud´s Public Data Store should be like this
An Array of 5 values:
[
XXXX-EEEEE-FFFFF,
SFSDFFWE-WERW-SDFS,
XXXX-XXXXX-XXXXX,
ZZZZZ-ZZZZ-ZZZZX,
XZXZZX-ZXZXZXS-ADADS
]
5.-All this will be executed every time you run the application, checking first if there is a value stored on the public cloud store. Here´s where I am confused, how will a different device know which UUID is yours? I mean, there are 5 different UUIDS to chose. Maybe it´s not supposed to be saved on the public data store, but on the private data store, but for that you would need to also identify each user. This is where I get so confused.
If there is no UUID set, execute the last 4 steps.
So, I get confused on the 5th step, most people understand that solution, without any more explanation, so I must be ignorant in the way something works, maybe the cloud services? I think the problem is that maybe I'm not understanding how the iCloud works, and how it stores it´s values. I just don't get how the 5th(random number, it might be the 2nd or 2000th) device of X running the app, will know that the UUID XXX... is the UUID of user X, and not the UUID of user Z.
Thank you again for answering so fast, I thought maybe I would have to wait a couple of days, not a couple of minutes. Forgive me for my ignorance, I'm kind of a noob on this matter, but I would like to learn. Been stuck on this problem for days
The answer you referred to is the correct way to identify your users. The solution is to save the value of that identification called a UUID (Unique User ID) - as opposed to a UDID (Unique Device ID).
The only down side to this of course for you as a developer is that the user could delete and install the app again and have a different ID.
As Daniel said, the UUID is the correct way to identify your users. I just want to add on this; you said that
I dont see how it would be unique to every new user
Well, accordint to this Wikipedia article:
Randomly generated UUIDs have 122 random bits...only after generating 1 billion UUIDs every second for the next 100 years, the probability of creating just one duplicate would be about 50%. The probability of one duplicate would be about 50% if every person on earth owns 600 million UUIDs.
So you can be pretty sure that the UUID will be unique to each user.
Additionally, the MAC address is based off of the MAC address of your ethernet card, the timestamp, and some other miscellaneous information. This adds to the uniqueness of the UUID as according to this question on Superuser:
[MAC addresses] are reasonably unique.
The first 3 octets define the manufacturer.
The last 3 octets are usually generated at the time of PROM burning. It's up to the manufacturer how they do this.
That obviously gives 16,777,215 possible unique MAC addresses per manufacturer. That's quite alot, so the manufacturer shouldn't re-use one.
So basically, the UUID adds an additional degree of uniqueness to the MAC address.
In summation, for your intents and purposes, the UUID would be perfect.
Hope this helps!
Backstory
This afternoon, I replied to a text from my girlfriend, then apparently neglected to sleep my phone before putting it back in my pocket. When I pulled it back out a few minutes later, my phone had decided to hit "Edit->Clear All" on the conversation, vaporizing two years and two phones worth of SMS history with her. While I have a backup of the phone, it's close to three weeks old at this point, and there's enough solid discussion that I'd like to reconstruct; I've already grabbed a copy of sms.db, but I think the method I used vacuumed the file, so there are no soft-deleted texts in it.
Meat of the Question
I have a three-week old backup of my sms.db, and have access to date copy of her sms.db. I'd like to
export the texts she has but I don't (easy, at least to CSV)
change the "perspective" info (the address field and the sent/received/deleted/unknown field), keeping the timestamp and text
import/merge these new entries into my old sms.db backup
merge this updated backup with my current sms.db (optional/there seems to be an online utility for that)
I don't really know SQL but would be willing to learn; the problem I have is that from what I understand, the tables within sms.db have become more interdependent over the OS's lifespan, and the triggers now call C functions that don't exist outside the phone, so it's not a simple matter of calling a single trigger on multiple entries. Does anyone know of any ways to work around this complexity, or even better, any utilities that have already figured out how to import individual entries into sms.db?
Edit:
I've been examining sms.db, and from what I can tell, the relationships are pretty straightforward:
for message, I need to mostly make sure that the ROWID of any added messages are higher than the current highest ROWID
msg_group holds the message:ROWID of the last message for each contact; I can lookup the correct address within group_member; group_member:group_id corresponds with msg_group:ROWID
msg_group has a hash column; this will probably be the hardest thing to update, since I'm not immediately sure what it's updating, or what hash to use
sqlite_sequencedoesn't seem like it's quite up-to-date; its entries seem to all be smaller than the actual ROWIDs, but I assume this means I won't have to mess with it very much.
I'm not really sure that I'll be able to change msg_pieces at all: it's the table in charge of handling the multiple parts of an MMS message.
Hey did you get this sorted out? if you haven't I suggest taking a look at http://smsmerge.homedns.org/
I have been in a similar position as you have, but I was lucky and had a more recent backup than that.
Let me know if you need a hand with it
I would like to include some type of copy protection scheme on my applications that would make a retail registered version of my software revert back to a trial version of my software if/when it gets installed on another computer.
In the old days I would simply store all the user information in a record that I tacked on to the end of the exe file. During the registration process I would simply poke those values into the data record on the end of the exe file. This worked great until good ol Norton started flagging my product as a virus because the exe file changed.
I stopped doing that a long time ago. I'm getting ready to create an updated version of my software and I'd like to know how you have accomplshed this.
The information that makes it a retail version should be stored on the target computer, not with the original program. That way, when they try to move the program, it reverts to the trial version because the retail information is missing on the new computer.
The retail information is added via a registration process, using a unique key. There are a number of ways to make this key work only once. One way is to transmit it directly to the program over the internet, where the user never sees it, so they can't manually transfer it to the new computer.
You should save the information in multiple locations to minimize the chance a savvy user can find it (using e.g. Process Monitor). I would suggest
a registry key in HKCU and
a hidden file in the local application directory.
Also save some information which is bound to the local computer, so even if the average user finds your file and registry entry copying won't succeed because they don't know how to obtain the updated data on a new PC. This information can also be a key generated by you based on some hardware ID the user has to send you.
Regarding the key generation algorithm: if the protection is "against" the average user then just make something up. This one depends a little bit on your target group. A simple one like ROT47 might be enough.
Perhaps you can use the same thing.
Except in stead of saving the data in the exe (invoking a false positive of the AV) hash and save the data in a separate file.
I'm looking to add a 14-Day trial limit to my software. The program has been written in Delphi 7.
Any help would be much appreciated.
You could try Turbopower OnGuard. This is now opensource.
http://sourceforge.net/projects/tponguard/
There are several tricks you can use, but none of them 100% fail save.
You can use some kind of licensing mechanism.
You can store the setup time somewhere hidden in the registry.
You can store the setup time in a file (possibly an executable file or dll).
You can store the IP address in a central database and check each time if the 14 days are passed (you need a internet connection for that).
You can create a file (for example a dll) dynamically on your server and have the installer retreive that file. (Be sure to log the IP so a second attempt will not be possible).
But I think the best way, is to give trial versions with limited functionality. For example: No printing, no save of project, or only small projects can be saved.
That way you avoid the hassle and possible clients can take the time to evaluate your project.
EDIT: If you build a mechanism to check against roling back the clock. Be sure to build in a margin, else the program will be locked if you travel back to an other timezone. Or put the clock back in wintertime. I think a margin of 25 hour will cover everything. (And to be at the save side, you can build in a limit else, the user can roll back the time each day.).
But the best way to keep paying customers, is giving good support. I discontinue products if the service is bad.
One of the things you need to guard against with a time-limited application is users' rolling their calendar back so the application still works. One way around this is to store in your hidden registry place (or wherever) a timestamp whenever the application is started up. If the current date/time is ever earlier than the last timestamp recorded by your app, that means the user has rolled the calendar back and you should disable the application.
Time-limitation is a real pain, though, both for the programmer and the user. It's also not a great marketing idea: why go to the trouble of distributing promotional material (which is what your trial version is) that has an expiration date? It would be like a company mailing out advertisements on paper designed to disintegrate after two weeks.
If your trial version is functionally crippled instead, you might still get sales out of it even months or years later.
You can find the similar question here.
On general note i find time restriction much more useful than functionality restriction. As i explained in the comment to Gamecat post
something to be aware of when performing any of these checks. That the date is never GREATER than 14 days from the date you entered in either direction. A common method around most of these types of limits is to set the date a few years in advance, install and run your software, then set the date back to the current time. If you are hard coded to die 14 days from the original start date, then the user has a few years to try your software. Checking the other direction also gives the user at most 28 days.
I have used Armadillo, Asprotect and Winlicense. Both Armadillo and Asprotect have had serious problems, such as being considered viruses/trojans by some AVs, incompatibility problems, etc.
I haven't used Winlicense enough to have much of an opinion, but support is pretty great.
Obviously both are more complete solutions than what you are asking for - they include protection, licensing, keys, etc.
As mentioned by others, sometimes limiting a feature or adding a watermark is the best option. I've added a watermark to one of my programs (STGThumb) and sales went up about 400%...
I would recommend making a trial serial number with timestamp and force user to enter it into software when its installed. You can even automate it by calling server side page after setup is done.
Timestamp in trial serial key allows you to extend their trial if needed.
In addition you can count backwards to avoid user from changing year when installing:
e.g. if you have 14 days trial generated at 15.11.2008 (server time), you can check that locate date must be greater than 1.11.2008 or less than 24.11.2008 always when serial is used or entered.
You can use a professional tool as SoftwareShield.
I use it in our apps and it provides several licence's models, including timelimited demo.
I created my own key generater (separate program for creating keys). The key values are stored in a binary file with the same name as my program, just a different ext. Example: myprogram.key
I store:
Name
Email
RegType (REG, TRIAL)
RegDate
FirstRun (0 OR 1)
The program looks for the file. If it is not there, it throws a message to the user and closes. The key file generator writes the values in encrypted strings which are then written using the built in stream routines.
I create a TRIAL Key that i distribute with the program. If someone registers, i then create them an official REG key.
Anway, if they are running my program, it first looks for the key file. if found, it checks the reg type, if its a regitered version, then the program loads, and the registration info is displayed. I also store a regdate, which i compare with the day the program runs and - if the regdate is greater than or equal to todays date, the user get sprompted to re-register.
If it finds that the key file stores a RegType of TRIAL, then the date they first ran it is stored in the keyfile, and the flag first run is set to 1. They can then use it for 14 days. Each time they run the program, the date stored is compared with the running date.
Very simple process to write. Is it fool proof? NO, nothing is! I have had great success with my app. Its not wide known, so there are no hackers lookijng to hack it.
The best would be to get the registration info from your server.
The big drawback: 1. The server must be ALWAYS online! 2. The user must be connected to internet (when it uses your app).
To get you started you can use a Delphi license management library to help you encrypt the license info and generate a string-based key that you can send to your customers upon registration. There are quite few libraries out there.
Anyway, whatever you send to your server needs to be based on the hardware fingerprint of that computer. Otherwise your license key will leak out on some warez website and everyone will be able to use that key. But if the key is hardware-based it would be useless if it is leaked on Internet.
And don't over do it! There is no such thing as unbreakable software protection. If Microsoft could not do it, you will not do it. Concentrate on adding nice features to your app instead of creating a bullet proof protection system (which is not possible).