I'm trying to understand the FIFO page replacement algorithm, but all the information I can find amounts to what's below. Can you explain how you use a reference string to evaluate a page replacement algorithm, using the particular example of FIFO?
When a page must be replaced, the oldest page is chosen.
In all our examples, the reference string is
1, 2, 3, 4, 1, 2, 5, 1, 2, 3, 4, 5
3 frame (9 page faults)
4 frame (10 page faults)
A page fault is when a page is not present in a frame of memory so a trap has to be sent to the OS
and the page has to be added to a frame. If there is no room then something needs to be removed.
FIFO is one method to determine what page will get removed.
The concept is that whatever page got added first to the frame will get removed first. This is what FIFO stands for. Using your first example. I will go down the reference string list and show you what the memory will look like.
1: 1 +1 fault
2: 1,2 +1 fault
3: 1,2,3 +1 fault
4: 2,3,4 +1 fault - 1 gets removed because it was the first added
1: 3,4,1 +1 fault - 2 gets removed because it was the first on the list
2: 4,1,2 +1 fault - 3 got removed..
5: 1,2,5 +1 fault - 4 got removed..
1: 1,2,5 No change - 1 is already present so no page fault was required
2: 1,2,5 No change - 2 is already present in the frame
3: 2,5,3 +1 fault - 1 was removed because it is first
4: 5,3,4 +1 fault - Now 2 got removed
5: 5,3,4 No change - No change because 5 is present in one of the frames.
This gives the total of 9 faults.
You can also think of it as the oldest page gets removed.
Hopefully I made no mistakes :D
------------ * FIRST IN FIRST OUT * -------------
Page no. 1 | 1 +1
Page no. 2 | 1 2 +1
Page no. 3 | 1 2 3 +1
Page no. 4 | 1 2 3 4 +1
Page no. 1 |
Page no. 2 |
Page no. 5 | 2 3 4 5 +1
Page no. 1 | 3 4 5 1 +1
Page no. 2 | 4 5 1 2 +1
Page no. 3 | 5 1 2 3 +1
Page no. 4 | 1 2 3 4 +1
Page no. 5 | 2 3 4 5 +1
Page Faults = 10
page replaced when not availbe in Queue.
go to this link FIFO
here explained all Page repalacemnt algo. very well with example. you understand easily.
1: 1 +1 fault
2: 1,2 +1 fault
3: 1,2,3 +1 fault
4: 2,3,4 +1 fault - 1 gets removed because it was the first added
1: 3,4,1 +1 fault - 2 gets removed because it was the first on the list
2: 4,1,2 +1 fault - 3 got removed..
5: 1,2,5 +1 fault - 1 got removed..
1: 1,2,5 No change - 1 is already present so no page fault was required
2: 1,2,5 No change - 2 is already present in the frame
3: 2,5,3 +1 fault - 1 was removed because it is first
4: 5,3,4 +1 fault - Now 2 got removed
5: 5,3,4 No change - No change because 5 is present in one of the frames.
Related
I have run into a behavior of Scala Observables that has surprised me. Consider my example below:
object ObservablesDemo extends App {
val oFast = Observable.interval(3.seconds).map(n => s"[FAST] ${n*3}")
val oSlow = Observable.interval(7.seconds).map(n => s"[SLOW] ${n*7}")
val oBoth = (oFast merge oSlow).take(8)
oBoth.subscribe(println(_))
oBoth.toBlocking.toIterable.last
}
The code demonstrates emitting elements from two observables. One of them emits its elements in a "slow" way (every 7 seconds), the other in a "fast" way (every 3 seconds). For the sake of the question assume we want to define those observables with the use of the map function and map the numbers from the interval appropriately as seen above (as opposed to another possible approach which would be emitting items at the same rate from both observables and then filtering out as needed).
The output of the code seems counterintuitive to me:
[FAST] 0
[FAST] 3
[SLOW] 0
[FAST] 6
[FAST] 9 <-- HERE
[SLOW] 7 <-- HERE
[FAST] 12
[FAST] 15
The problematic part is when the [FAST] observable emits 9 before the [SLOW] observable emits 7. I would expect 7 to be emitted before 9 as whatever is emitted on the seventh second should come before what is emitted on the ninth second.
How should I modify the code to achieve the intended behavior? I have looked into the RxScala documentation and have started my search with topics such as the different interval functions and the Scheduler classes but I'm not sure if it's the right place to search for the answer.
That looks like the way it should work. Here it is listing out the seconds and the events. You can verify with TestObserver and TestScheduler if that is available in RXScala. RXScala was EOL in 2019, so keep that in mind too.
Secs Event
-----------------
1
2
3 [Fast] 0
4
5
6 [Fast] 3
7 [Slow] 0
8
9 [Fast] 6
10
11
12 [Fast] 9
13
14 [Slow] 7
15 [Fast] 12
16
17
18 [Fast] 15
19
20
21 [Fast] 18
I have made a very simple patch, by which when a bang is triggered, it is meant to trigger a unique number between 0-2, in other words, no numbers are repeated.
In the way that I set it up, it is meant to work in theory. Even my programming mentor said that it should work, in theory, and he's generally a very smart man. He's informally known as being the boffin of the academy.
A few more details:
This happens in both purr data and pure data, with the exact same setup.
There are no external libraries are used. Just plain Vanilla objects.
Since there doesn't seem to be a way to attach the actual file itself, I will instead post an image of the code:
The problem is with depth-first processing (as used by Pd) and the related stack-unrolling, as this might lead to setting the 2nd input of [select] to an old value (which you didn't expect).
Example
Note: select:in0 means the left-most inlet of [select],... The numbers generated by [random] are shown in bold (1) and the numbers output the patch are shown in bold italics (e.g. 3)
Imagine the [select] is initialized to 0 and the [random 3] object outputs a list 2 0 0 2 0 2 ... (hint: [seed 96().
The expected output would be 2 0 2 0 2 ..., however the output really is 2 0 2 2 2 ...
Now this is what happens if you consecutively send [bang( to the random generator:
random generates 2
2 is sent to the sel:in0, which compares it to 0 (no match)
and sends it out of sel:out1 (the reject outlet), displaying the number 2
after that the number is sent to sel:in1, setting it's internal state to 2.
random generates 0
0 is sent to the sel:in0, which compares it to 2 (no match)
and sends it out of sel:out1, displaying the number 0
after that the number is sent to sel:1, setting it's internal state to 0.
random generates 0
0 is sent to the sel:in0, which compares it to 0 (match!)
and sends a bang through sel:out0 (the match outlet)
triggering a new call to random, which now generates 2
2 is sent to the sel:in0, which compares it to 0 (no match)
and sends it out of sel:out1, displaying the number 2
after that the number is sent to sel:1, setting it's internal state to 2.
after that the number 0 (still pending in the trigger:out0) is sent to sel:1, setting it's internal state to 0!!!
random generates 0
0 is sent to the sel:in0, which compares it to 0 (match!)
and sends a bang through sel:out0
triggering a new call to random, which now generates 2
2 is sent to the sel:in0, which compares it to 0
and sends it out of sel:out1, displaying the number 2
after that the number is sent to sel:1, setting it's internal state to 2.
after that the number 0 (still pending in the trigger:out0) is sent to sel:1, setting it's internal state to 0!!!
As you can see, at the end of #3 the internal state of [select] is 0, even though the last number generated by [random] was 2 (because the left-most outlet of [trigger] will only send to 0 after it has sent the 2, due to stack-unrolling).
Solution
The solution is simple: make sure that the state of [select] contains the last displayed value, rather than the last one generated on the stack. avoid feedback when modifying the internal state.
E.g (using local send/receive to for nicer ASCII-art)
[r $0-again]
|
[bang(
|
[random 3]
|
| [r $0-last]
| |
[select]
| |
| [t f f]
| | |
| | [s $0-last]
| |
| [print]
|
[s $0-again]
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 5 years ago.
Improve this question
I need the help of someone who wants to collaborate with the solution of the following problem, I am validating the digital signatures of a PDF with ITEXT, this works very well, the problem that I can not validate the signature is when I have 2 signatures and the first one is invalid , As indicated by Adobe Acrobat, but with the examples of itext consider it as valid, some help please?
To begin with, Adobe Reader does not complain about a signature becoming invalid because of changes to the signed bytes of the first signed revision but because of additions in the incremental update section to the second signed revision which it considers disallowed.
Neither iText nor PDFBox (which originally also had been mentioned in a tag of the question) check this in their standard signature validation code. Thus, even if the addition in question was disallowed, neither iText nor PDFBox signature validation code would have recognized that.
Actually I don't know whether any PDF product other than Adobe Acrobat / Adobe Reader tries to check whether additions in incremental updates to signed PDFs are disallowed or not.
That being said, even Adobe's tests in this regard are not very good: When they check whether some change is allowed, they often actually check whether the change is executed in a manner Adobe would have executed an allowed change. Thus, if you do some allowed change in a different way, Adobe is likely to claim a disallowed change.
This also is the case in the sample document Con firma fallada.pdf.
In the first signed revision the PDF Catalog object looks like this (pretty printed):
1 0 obj
<<
/Type/Catalog
/ViewerPreferences 2 0 R
/Pages 29 0 R
/AcroForm
<<
/DA(/Helv 0 Tf 0 g )
/Fields[32 0 R]
/SigFlags 3
/DR<</Font<</Helv 33 0 R/ZaDb 34 0 R>>>>
>>
/Outlines 3 0 R
>>
endobj
In the incremental update to the second signed revision an additional signature field has been added, so the object had to be rewritten. The signing software additionally refactored the direct AcroForm dictionary object into a new indirect object:
1 0 obj
<<
/Pages 29 0 R
/AcroForm 35 0 R
/Type /Catalog
/ViewerPreferences 2 0 R
/Outlines 3 0 R
>>
endobj
35 0 obj
<<
/DA (/Helv 0 Tf 0 g )
/DR << /Font << /Helv 33 0 R/ZaDb 34 0 R >> >>
/Fields [ 32 0 R 36 0 R ]
/SigFlags 3
>>
endobj
With this in place, Adobe claims a disallowed change.
If one replaces the above with an equivalent version using a direct AcroForm dictionary object, Adobe does not claim that disallowed change anymore:
1 0 obj
<<
/Pages 29 0 R
/AcroForm
<<
/DA (/Helv 0 Tf 0 g )
/DR << /Font << /Helv 33 0 R/ZaDb 34 0 R >> >>
/Fields [ 32 0 R 36 0 R ]
/SigFlags 3
>>
/Type /Catalog
/ViewerPreferences 2 0 R
/Outlines 3 0 R
>>
endobj
This, by the way, is exactly how the Catalog looks like in the incremental update with a second signature in Con firma buena.pdf.
(Curiously, though, in that file there also is a copy of the direct AcroForm dictionary object in the indirect object 35; probably a sign of someone testing. As that object is not referenced, though, it does not disturb any check...)
When looking a packet byte code, how would you identify a dns packet.
The IP header's protocol field would tell that a UDP frame follows, but inside the UDP frame no protocol field exists to specify what comes next and, from what I can see, there is nothing inside the frame that would uniquely identify it as a dns packet.
Other than it being on port 53, there's a few things you can look out for which might give a hint that you're looking at DNS traffic.
I will refer to the field names used in §4.1 of RFC 1035 a lot here:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR| Opcode |AA|TC|RD|RA| Z | RCODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QDCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ANCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| NSCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ARCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
As you can see above the header is 12 bytes long - a 2 byte ID, 2 bytes of flags, and 4 x 2 bytes of counts.
In any DNS packet the QDCOUNT field will be exactly one (0x0001). Technically other values are allowed by the protocol, but in practise they are never used.
In a query (QR == 0) the ANCOUNT and NSCOUNT values will be exactly zero (0x0000), and the ARCOUNT will typically be 0, 1, or 2, depending on whether EDNS0 (RFC 2671)and TSIG (RFC 2845) are being used. RCODE will also be zero in a query.
Responses are somewhat harder to identify, unless you're observing both sides of the conversation and can correlate each response to the query that triggered it.
Obviously the QR bit will be set, and as above the QDCOUNT should still be one. The remaining counters however will have many and varied permutations. However it's exceedingly unlikely that any of the counters will be greater than 255, so you should be able to rely on bytes 4, 6, 8 and 10 all being zero.
Following the headers you'll start to find resource records, the first one being the actual question that was asked (§4.1.2). The unfortunate part here is that the designers of the protocol saw fit to include a variable length label field (QNAME) in front of two fixed fields (QTYPE and QCLASS).
[To further complicate matters labels can be compressed, using a backwards pointer to somewhere else in the packet. Fortunately you will almost never see a compressed label in the Question Section, since by definition you can't go backwards from there. Technically a perverse implementor could send a compression pointer back into the header, but that shouldn't happen].
So, start reading each length byte and then skip that many bytes until you reach a null byte, and then the next two 16 bit words will be QTYPE and QCLASS. There are very few legal values for QCLASS, and almost all packets will contain the value 1 for IN ("Internet"). You may occasionally see 3 for CH (Chaos).
That's it for now - if I think of anything else I'll add it later.
How about checking the port number? Should be 53 for both source and target port.
I added an entry to memcached and looking at the cachedump.
set a 0 0 5
hello
STORED
stats cachedump 1 5
ITEM a [5 b; 1312548967 s]
END
The first value 5 b is size of the item which is 5 bytes. The second one is what I'm confused about. It looks like time since epoch.
I tried adding another entry and even that entry got exactly same value.
set b 0 0 5
hello
STORED
stats cachedump 1 5
ITEM b [5 b; 1312548967 s]
ITEM a [5 b; 1312548967 s]
END
It looks like some kind of time, but I'm not sure what it really is. Can some one explain it?
This is meant for debugging purposes only and will very likely be removed soon.
You're invited to participate in that conversation. Please let us know what you're interested in.