Here is the code I'm talking about:
md.reset();
What does the reset() method do to the MessageDigest object? Why is it necessary?
It returns the MessageDigest instance back to its initial state, so that you can use it again for calculating another message digest (as opposed to getting a new instance, which could be expensive or inconvenient).
If you did not call this method, but continued to just shove the second message in, the resulting digest might not be correct (as it could contain "junk" left over from the previous calculation).
Related
I am not sure why the data is not loading in?? It was working fine before, then all of a sudden any file I try to read in just returns async
INPUT: data = FileAttachment("cincinnati_store.json").json
OUTPUT FROM CELL: data = async ƒ(…)
It looks like you need parentheses after .json. So, the input of the cell should look like:
data = FileAttachment("cincinnati_store.json").json()
You need the parentheses because json is a method on the FileAttachment (i.e. a function you have to call). That’s as opposed to something like the length of a JavaScript array, which is a property of the object, so you can just call myArray.length without parentheses. It’s fair to be confused by this — different objects do it differently, so you sort of just have to know (or look up) what’s what!
You get a hint there in the output of the cell (the “inspector”) because it’s telling you that the value of what you’ve put in is an asynchronous function. It’s showing you the function itself, as opposed to the return value of calling the function, so you can tell that you have to call it to get the Promise that resolves to your cincinnati_store.json data.
If that doesn’t work, if you post a link to your notebook I’d be happy to take a look.
After I call the ChannelWriter.wite() method to send a message, it returns me a ChannelFuture. If the receiving end on the other side has disabled read in epoll_wait, I think the socket write is supposed to be partially complete since zero bytes are supposed to be written. I thought of using the returned ChannelFuture, but isSuccess() returns true.
How do I know if the ChannelWriter.write() was only partially complete or zero bytes written?
It will only notify the future once the whole bytes are even written or if the write failed.
I am using pseudo-synchronous sockets in a Windows Phone 7 application. My socket code is based on the sample from http://msdn.microsoft.com/en-us/library/hh202858(v=vs.92).aspx.
The server's sending pattern is somewhat unpredictable. It starts with a fixed-size header that contains the length of the rest of the message. I first read in this header, and then I read the specified number of bytes from the socket.
Since I need to send messages to the server as well, and my attempts at duplexing the socket with a thread for receiving and another thread for sending caused lots of problems, I have a loop like this in my code:
while (KeepConnectionGoing)
{
byte[] Rcvd;
Rcvd = Socket.Receive();//Returns null if no message received in 50 ms
if (Rcvd != null)
{
ParseMessage(Rcvd);
}
if (HasMessageThatNeedsToBeSent())
{
byte[] Message = GetMessageToSend();
Socket.Send(Message);
}
}
This works fine for the majority of the time, but strange things happen when the message is null.
Because the timeout in the Receive method (see the linked sample) uses a ManualResetEvent, the receive request on the socket is never actually cancels. Even though the method returns, that request waits around somewhere, and when data is available on the socket, chomps up the header. The event handler has nothing to do with the data it received (since the method has returned and the variables in the method will never be used again), the data basically disappears. The read request I expect to return the header skips reads the bytes after the header, and I have no idea how long the message is.
I'd like to be able to cancel all outstanding requests if the socket times out. I am using anonymous methods like in the sample since it simplifies everything and prevents me from having to write all the state transfer code myself. Thus, I cannot unhook the event handler. I think though, that even if I were using a method as the event handler, but unhooking before the asynchronous operation is done, the callback method would still be called. (I haven't tested this, it's just my understanding)
Right now, the only solution I can see is hacking together some static byte arrays (ie. having a static byte[] Header and if it is null, I read the header, otherwise I read the message), but that seems like a really inelegant solution and very prone to race conditions.
Is there a better way?
Thanks
It appears there really is no good way to do this. A poll method would be nice, but Silverlight doesn't have it. I hacked together a solution using static flags to tell me what state I am in (Has the header been requested, has the message been requested), a static int for the length and a static buffer.
At the beginning of the method, either the header or the body can be requested. If the header has already been requested, the thread waits until a valid body length is available. If this wait times out, that means that the header receive operation is still pending, but there really is no message available. Otherwise, it reads in that length of a message.
If the header has not been requested, receive the header. In the event handler, after completion, check to see if the control flow has already continued (i.e. the receive operation took too long, so the function returned already, but is now actually done). Update the length, then request the body unless it timed out.
I had protobuf.net deserialize invalid (random) bytes into a KeyValuePair (i.e. not nullable). Instead of (as expected) an exception being thrown, an empty struct was returned.
Since this default struct could be valid data, I don't see a way to tell if the source data are actually valid. Is this a bug, or is there a way I'm missing?
(protobuf-net 2.0.0.480, 2011.12.11)
Update:
There were scenarios in v2 where it wouldn't spot this, but would instead terminate as though it had reached the end of the stream - in particular if the "field number", after applying shifts, was non-positive. However, this is not valid in a protobuf stream, and this will be fixed next build.
That depends on quite how random it was ;p Actually, getting that to do anything without throwing an error is pretty impressive - the protobuf spec is pretty specific about layout, and normally it will throw a big exception there (probably mentioning "unexpected wire-type" or similar).
Emphasis: in almost all cases it will throw an exception. If you fluke some data of the right spec, but different field numbers, then it will silently ignore the unexpected data, and you'll get an all-zero struct. If you fluke some data of the right spec, but with the right field numbers and layout, you'll get garbage. But that is like saying
if I randomly generate data that by pure chance happens to be {"foo":"0"}, JavascriptSerializer doesn't complain!!! bug!!!
Are you sure you actually deserialized some data here? and that the stream wasn't already the EOF position? For example, the following won't error, as you haven't rewound the stream - you are effective deserializing zero bytes:
var ms = new MemoryStream();
ms.Write(randomBytes, 0, randomBytes.Length);
var obj = Serializer.Deserialize<Foo>(ms);
(and zero bytes is perfectly valid for a protobuf object)
If you want to test a stream for validity, you can use ProtoReader, just skipping (SkipField() or something similar) every field until ReadNextHeader() (or whatever) returns a non-positive integer.
Is it a function?
Is it a function being called from the source?
Or, is it a function being returned from the destination?
Or, is it just executing a function at the destination?
Or, is it a value returned from a function passed to the destination?
A callback is the building block of asynchronous processing.
Think of it this way: when you call someone and they don't answer, you leave a message and your phone number. Later on, the person calls you back based on the phone number you left.
A callback works in a similar manner.
You ask an API for a long running operation and you provide a method from within your code to be called with the result of the operation. The API does its work and when the result is ready, it calls your callback method.
From the great Wikipedia:
In computer programming, a callback is
executable code that is passed as an
argument to other code. It allows a
lower-level software layer to call a
subroutine (or function) defined in a
higher-level layer.
Said another way, when you pass a callback to your method, it's as if you are providing additional instructions (e.g., what you should do next). An attempt at making a simple human example follows:
Paint this wall this shade of green (where "paint" is analagous to the method called, while "wall" and "green" are similar to arguments).
When you have finished painting, call me at this number to let me know that you're done and I'll tell you what to do next.
In terms of practical applications, one place where you will sometimes see callbacks is in situations with asynchronous message passing. You might want to register a particular message as an item of interest for class B.
However, without something like a callback, there's no obvious way for class A to know that class B has received the message. With a callback, you can tell class B, here's the message that I want you to listen for and this is the method in class A that I want you to call when you receive it.
Here is a Java example of a callback from a related question.