Wikipedia has a long list of standard port numbers for various protocols.
Does anyone know how some of these numbers were chosen?
EDIT: I'm asking how/why the original developers chose the numbers, not where the list comes from.
This mailing list thread has some insight
The first reference to a registry of well known numbers seems to be RFC 322, from 1972. RFC 433 is the first official compilation of such a registry. There is a bit of background on Wikipedia describing the history of the IANA which talks about this.
Read the wikipedia page on the IANA (Internet Assigned Numbers Authority). Early on the designers of the protocols picked the port numbers and maintained a registry. Overtime these became the official numbers and people agreed to use them for those protocols and not for other programs. Eventually these became codified in the RFCs and the IANA was born to manage the process.
Nowadays, the port numbers are handed out by http://iana.org.
Related
In International Patient Summary (IPS), how is it expected to uniquely identify a cross-border Patient?
To elaborate, IATA has a way to track all passengers across the globe. How can the healthcare systems do that?
I'm unable to figure this from hl7 documentation and implementation guides. Any help is appreciated.
That's a good question. There certainly isn't anything like a "global MPI" that's available, of course, and I think your question fairly points out that we haven't explicitly provided a solution for this in the IPS and our other HL7 specifications. For "international" use in the patient summary and specifically for supporting cross (national) border patient care, I don't think that we can give an absolutely definitive answer, but I think that there are some reasonable ways that we should be able to deal with this issue. I'm thinking of two in particular at the moment. The first is that in cases where there is dedicated organization and infrastructure (I'm thinking of something like the European cross-border services) then it may well be possible to provide some type of MPI service(s) that can establish and verify identity across the jurisdictional boundaries (and I'm not saying that for sure this actually exists in Europe or anywhere else, but just that it may be possible to do). The second, which I expect will turn out to be the more common and useful case overall, is that the patient is the ultimate owner of his or her data, so if the patient transports and provides the data directly to the receiving clinician (e.g., via their mobile device) then that should be more than sufficient to establish the identity. In that case the provenance and reliability of the data may still need to be considered, but that is a different question. Hopefully that may help a little! It is something that I agree we probably will need to address further in future versions of the IPS.
Rob
I've tried to get an answer to this question in VB IRC channel, I've looked around stackexchange, stackoverflow, superuser, and elsewhere. Answers come close, but not what I am wanting to know.
This is a curiosity question only, not one of necessity. I just want to know how things work. It has nothing to do with any bug, enhancement request, or security issue. If you feel this forum is not the place to get an answer to this, please refer me to the proper venue. Thanks. (Although it is hard for anyone to imagine that VBox's own forum could be the wrong place, I did not see an answer to my specific question or a place to post to an appropriate category.) Whatever happens, please don't close my question without at least pointing to a better resource (I hate when that happens!). Thanks again.
Now, the question: How does virtualbox's host driver calculate the total number of virtual CPU's to provide?
(Please note I will not respond to answers from people who did not really read the question, or at least first ask for more clarification. I think this is a VERY straight-forward question.)
Let me break the question down so as to be as precise and concise as possible as to what I am really asking. I am curious to know how the VirtualBox HOST software (whatever portion that may be) determines how many VIRTUAL CPUs appear on the configuration interface where the user selects how many VCPUs they would like to apply to a specfiic VM.
What I am NOT asking: I am NOT asking about the miracle of virtualization hardware, etc., in general; I understand multiple cores and multiple threading, VTx, etc. I am NOT asking how many I should use for a specfic VM or application. I am NOT asking for help in configuring any specific VM in my question. I am NOT asking anyone to ask ME why I need to know -- I told you already; I am merely curious. If my specific question does not interest you, that's fine. Again, this is just a simple, straight-forward question: How does VBox arrive at the number?
What I already know: It is true that, at least generally, the answer is 2x as many as physical CPUs; OK, if so, why 2x and not 3x or some other multiplier? (I know fractional amounts won't work for odd-number of cores or threads; I am just being as general as I can be.) For instance, on my Phenom II X6, VirtualBox presents me with up to 12 VCPUs. If the answer is the threads, well, that can't be since my particular Thuban does not have threads (some Thubans do, some don't). What my Thuban DOES have, though, is hypertransport, but not hyperthreading. Likewise, my old Phenom II X2 will allow 4 VCPU's in Virtualbox.
I have already read the numerous responses on the sites mentioned above admonishing users NOT to use more than one VCPU per VM because it adds overhead (for one thing, you must run the IOAPIC, which introduces a performance hit). I've also read posts where the question sounds like mine, but they do not ultimately give an answer to this.
Is the answer some kind of sigma sum or logarithmic formula? Is it complex enough to exceed this forum's formatting capabilities? Hard to imagine why it is so difficult to get an answer to this, which I figure would have been asked and answered many times over. I really want to know why it seems to be 2x usually; why that is the "magic" number. If I read the source code (assuming this is available), will the comments explain why?
I will really appreciate and admire the soul(s) who read and answer this question, and not some other question not being asked. I also hope you will not redirect me to the dark and hostile channels of IRC; there are some very sociopathic entities on IRC whose remarks remind me of some of the unsubs on Criminal Minds. Note that I said "some" -- there are helpful people there also. Not meaning to antagonize; I just hate going to IRC anymore. If you know of a specfic helpful nick on IRC with this, I'd appreciate that also.
BTW, I have been googling for answers to this and other questions and reading SO, SE, and SU boards and I see where some people respond with answers that are totally irrelevant. That's the reason for what may sound like a harsh tone by me. This is my first post, and I hope the response will be more positive than a few of my experiences on IRC.
It seems you are asking "How does the VirtualBox GUI calculate the available range for the Processor(s) slider under the System settings?"
Because VirtualBox is open source (and very clean, well written source) it isn't too hard to dig into the code and research out the answer. Digging down into the /src/VBox/Frontends/VirtualBox/src/settings/machine folder you can see all the UI* files that comprise the settings UI elements. The specific file that will have your answer is UIMachineSettingsSystem.cpp. Starting on about line 45 (as of revision 43459), you can see the following code:
/* Setup constants */
CSystemProperties properties = vboxGlobal().virtualBox().GetSystemProperties();
uint hostCPUs = vboxGlobal().host().GetProcessorCount();
mMinGuestCPU = properties.GetMinGuestCPUCount();
mMaxGuestCPU = RT_MIN (2 * hostCPUs, properties.GetMaxGuestCPUCount());
The mMinGuestCPU variable and associated GetMinGuestCPUCount() method (and mMaxGuestCPU / GetMaxGuestCPUCount()) should be relatively straightforward - typically it will be 1 for the min and the max will be the number of physical/logical cores available on the host.
Thus, to answer your question - the scale for the slider is typically 1 through two times the number of cores available. I would strongly encourage you to download the source code and dig into the methods that calculate those numbers and see for yourself how they are calculated and the nuances that are involved. Specifically the vboxGlobal().host().GetProcessorCount() method.
While googling I could find only feistel ciphers and didn't find any relevant information on non-feistel ciphers. Can someone suggest me some good non-feistel ciphers?
And yes this is homework.
There's way more than Feistel ciphers. :)
The simple answers: No stream ciphers, such as rc4, are Feistel ciphers. No Public Key ciphers, such as RSA or El Gamal are Feistel ciphers.
And the perhaps-surprising counter-example: Rijndael (the new AES), despite being a block cipher, isn't Feistel.
If you're really interested in Cryptography, I strongly recommend reading Handbook of Applied Cryptography, freely available and significantly better than most undergraduate texts. Schneier's "Applied Cryptography" is decent enough, an excellent introduction, but doesn't get into as much detail as one might like.
Rijndael, Square, Serpent, IDEA, Noekeon, etc. Wikipedia has a list of blockciphers, and the structure (Feistel, Feistel-like (unbalanced Feistel, e.g.), Substitution-Permutation network (SPN), etc. is mentioned in each lemma. SPN and Feistel are the most common, as the design makes it obvious that the function will be invertible. Designs other than these are rarer, but do occur. All the ciphers in the standards (like SSL/TLS, SSH, etc.) are of one of these 2 types.
I suggest putting in a little more effort. Even a cursory on-line search turns up definitions of "Feistel cipher", as well as descriptions of a wide variety of cipher procedures- It should not be too hard to tell which are clearly not Feistel ciphers.
I further recommend finding a good book on the subject, such as Bruce Schneier's "Applied Cryptography" (either edition).
I want to produce a random cryptographic key on Windows. Where can I obtain entropy?
I would like my entropy function to work without a network connection and to be reliable on Windows 2000 and upwards. Even sources which may or may not provide a small amount of entropy could be useful as all the sources will be pooled.
This is my initial list of functions:
GetCurrentProcessID,
GetCurrentThreadID,
GetTickCount,
GetLocalTime,
QueryPerformanceCounter,
GlobalMemoryStatus,
GetDiskFreeSpace,
GetComputerName,
GetUserName,
GetCursorPos,
GetMessageTime,
GetSystemInfo,
CryptGenRandom,
GetProcessHandleCount,
GetProcessMemoryInfo.
Although early versions of the CryptGenRandom function may contain weaknesses later versions follow secure standards (see remarks on the CrypGenRandom page.)
It is weak to just use time as your seed. There is an answer under What is the most secure seed for random number generation? which explains that the unpredictable random seed may only need 128 bits to produce a secure PRNG. It is therefore probably unnecessary to find more sources than those listed in the question, and normally the CryptGenRandom function will already contain and generate enough entropy for itself that the caller does not need to do any of this.
CryptGenRandom and the function CryptAcquireContext which must preceed it can be called from Delphi like this.
If its an option you can ask user to move mouse pointer for a while.
The only external source that most machines have is Mic In/Line In, call waveInOpen+waveInPrepareHeader+waveInAddBuffer+waveInStart. How random that is probably depends on the hardware...
I have an AT89S52, and I want to read the program burned on it.
Is there a way to do it with the programming interface?
(I am well aware it will be assembly code, but I think I can handle it, since I'm looking for a specific string in that code)
Thanks
You may not be able to (at all easily anyway) -- that chip has three protection bits that are intended to prevent you from doing so. If you're dealing with some sort of commercial product, chances are pretty good that those bits will be set.
Reference: Datasheet, page 20, section 17.