|
In general terms, yes, "hashing" has a wider meaning than "a cryptographic hash function".
In the context of the original question, I think it's reasonable to assume that the OP was referring to "a cryptographic hash function", and not any of the other possible meanings.
But given the OP's history as a help vampire, and the fact that he could have answered his own question by spending five minutes in Google, I also think it's reasonable to ignore the question, or direct him to Google.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
My point is always to get the "OP" to clarify their OWN question.
The fact that everyone needs to jump in an "reinterpret" my intentions is their problem.
The fact that I am not always "obvious" about it, is also not my problem.
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
Gerry Schmitz wrote: You want to play with hashing algorithms for "password security"? Not on my watch.
The hashing algorithms used for passwords are considerably more secure than any encryption: SHA-512 for example generates a 512 bit hash value from the (hopefully salted) user password input. This is compared with the stored hash - so the "clear text" password is never transfered out of the authenticating system - and a match confirms the input. This gives you in theory a 1 : 1.34078079e154 chance of a collision or "false positive" assuming that the hashing algorithm gives no weight to any particular range of output values. You cannot regenerate the original input from the hashed value.
Encrypted password on the other hand are seriously insecure: the decryption key has to be available to the "check the password" code and that means that it's effectively stored with the encrypted data.
Please, do tell us which security systems you have implemented encryption for, so we can avoid them or ensure that we only ever use a "one-time" password (which I do anyway, no two of my logins have the same password, and I use an encrypted password store to hold them - the password to that is only ever stored in my head...)
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
I use Windows Authentication.
I don't presume to know more.
I said there would be colissions; you want to quibble about the number.
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
And how do you think Windows stores your password?
For use in Windows networking, including Active Directory domains, the password is stored two different ways by default: as the LAN Manager one-way function (LM OWF) and as the NT OWF. "One-way function" is a term that denotes a one-way mathematical transformation of data. ... The most common type of one-way function in use is a cryptographic hash.
Although interestingly, Microsoft have added to the confusion by referring to "encryption" in the same sentence.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
In this case, I don't care and don't need to know.
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
Never thought about using Google for such basic researches ?
Patrice
“Everything should be made as simple as possible, but no simpler.” Albert Einstein
|
|
|
|
|
I was thinking about the design I posted here. So I decided to create a prototype. I welcome your thoughts.
Service Base Class
public abstract class ServiceBase
{
public enum States
{
Cancelled,
Processing,
Stopped
}
#region Properties
public States CurrentState { get; protected set; }
public Guid ServiceId { get; private set; }
public CancellationTokenSource CancellationTokenSource { get; private set; }
#endregion
#region CTOR
public ServiceBase()
{
this.CurrentState = States.Stopped;
this.ServiceId = Guid.NewGuid();
this.CancellationTokenSource = new CancellationTokenSource();
}
#endregion
#region Abstract Methods
public abstract void Start();
public abstract void Stop();
#endregion
#region Public Methods
public void Cancel()
{
this.CurrentState = States.Cancelled;
CancellationTokenSource.Cancel();
}
#endregion
#region Private Methods
protected bool CheckIfCancelled(bool throwIfCancelled = false)
{
bool cancelled = false;
var token = CancellationTokenSource.Token;
if (token.IsCancellationRequested)
{
cancelled = true;
if (throwIfCancelled)
{
token.ThrowIfCancellationRequested();
}
}
return cancelled;
}
#endregion
}
The goal is here to have this base class create and store its own CancellationTokenSource. Then, calling Cancel() on it would allow callers from outside to cancel it. Cancelling is to cancel the Task that it's running it, where Start() and Stop() control the service's procssing.
Service Implementation
Here's an implementation example of that class:
public class MyService : ServiceBase
{
#region Public Methods
public override void Start()
{
CheckIfCancelled(true);
CurrentState = States.Processing;
while (CurrentState == States.Processing)
{
if (CheckIfCancelled())
{
break;
}
}
}
public override void Stop()
{
CurrentState = States.Stopped;
}
#endregion
}
The purpose of this design is to wrap the Cancel code in the base class, so simple implementations like this only need a simple method call to figure out if it's been cancelled.
Usage
The, the Windows Service, which is hosting all the services, looks like this
private static List<ServiceBase> _services;
static void Main(string[] args)
{
_services = new List<ServiceBase>();
<pre>
for (int x = 0; x < 100; x++)
{
MyService service = new MyService(); // See the CTOR of ServiceBase
_services.Add(service);
}
// Start each service
foreach (var service in _services)
{
Task.Factory.StartNew(() =>
{
service.Start();
}, service.CancellationTokenSource.Token);
}
}
Notice that the Task.Factory.StartNew gets the Cancellation Token from the service class.
Stopping or Cancellign
Later on, when it comes time to stop processing, or to Cancel a task, I can do the following:
private static ServiceBase GetServiceById(Guid serviceId)
{
var service = _services.Where(x => x.ServiceId ==1 serviceId).FirstOrDefault();
return service;
}
var s1 = GetServiceById(_services.FirstOrDefault().ServiceId);
s1.Stop();
var s2 = GetServiceById(_services.Last().ServiceId);
s1.Cancel();
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
Your Start method does not return. Use it to create the internal thread and start that thread.
private bool _keepRunning;
public void Start()
{
_keepRunning = true;
Thread thread = new Thread(MainFunction);
thread.Start();
}
private void MainFunction()
{
while(_keepRunning)
{
try
{
}
catch(Exception ex)
{
}
Task.Delay(some time);
}
}
public void Stop()
{
_keepRunning = false;
} You don't need a CancellationToken here; a CancellationToken is used for cancelling a thread in circumstances where you do not have other possibilities of stopping it; consequently, it must be available outside of the thread, too: it must be shared between the thread to be cancelled and the item requesting the cancellation.
Also, you can now start your services in a "common" for/foreach loop.
|
|
|
|
|
Thanks for your input. Interesting approach.
I guess I was thinking that I wanted the Windows Service to create the threads. I'm trying to make this design so that other developers don't have to worry about the threading. They will only need to code up the Start() method with the services' code and leave the threading portion to the Windows Service.
As far as cancelling goes... I'm trying to make a clear distinction between cancelling a thread for the purpose of uninstalling a service, and stopping it which really means "pause" its processing.
These services will be loaded and launched via a scheduler process, so that's why I put the start portion in the Windows Service and included the CancellationToken.
Bernhard Hiller wrote: it must be shared between the thread to be cancelled and the item requesting the cancellation.
Note that the token is retrieved off the Service itself
foreach (var service in _services)
{
Task.Factory.StartNew(() =>
{
service.Start();
}, service.CancellationTokenSource.Token);
}
So, while I like your idea, is there any reason that you can see why my design wouldn't work?
Thanks
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
You've been putting a lot of work into this, and I'm glad to see that you have a product gelling.
I have to agree with Bernhard on his point about external tokens as a control measure.
I have also have gone down this road, and I've found that having some event hooks for individual component recycling and monitoring go a long way to making this sort of host service work more effectively.
"There are three kinds of lies: lies, damned lies and statistics."
- Benjamin Disraeli
|
|
|
|
|
Something I would consider, if I were you, is some form of heartbeat capability. Basically, you would use the heartbeat to determine whether or not a service is alive.
This space for rent
|
|
|
|
|
By heartbeat I assume you mean some kind of ping from the server into the client?
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
I also wanted to ask what are the best frameworks to improve the appearance of buttons. Microsoft has made no effort in this regard. I use DevComponents DotNetBar but it seems that few people use it and wanted to know what you are using.
modified 29-Mar-17 7:19am.
|
|
|
|
|
Regequion wrote: Microsoft has made no effort in this regard. I prefer plain WinForms, because of the effort they have made.
It is a very recognizable button, and it will look like that uniformly across all applications. There is no guessing involved for the user on what the control would do or how to use it.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Have you looked at WPF? With WPF you can do anything you want to any element, so you can create the look and feel you need with very little work.
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
This is a bit long but I really need some validation on my project. I would appreciate your thoughts on the overall design and also my questions at the end
Overview
I'm creating an app that will run individual assemblies (called "Services") in a Windows Service. The Windows Service will really just be a host for the service classes that can be run according to a schedule. A "Service" is just an an assembly that implements an interface. Its run duration is determined by a schedule. It can run one time, or repeatedly according to scheduling options.
The Windows Service will be running on remote instruments around the world. The Windows Service will listen to a SignalR service running on our server that will all us to install, start, stop, disable, remove, or change the schedule for any or all of the "Services" on a particular instrument.
An example of a use case is diagnostics. A service will execute every 5 minutes to query a local DB for error records, then report its findings back to our server. The will be other use cases as well.
Details
On startup of the Windows Service the app will load services from a 'manifest'. This file is just a serialized list of services to load and when to run them. If an assembly is not runable (because the schedule says not to run, or it's been disabled), the it's not loaded.
Here's the manifest, not including the scheduling details.
<?xml version="1.0" encoding="utf-8"?>
<ArrayOfService xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<Service>
<ServiceName>TestClass1</ServiceName>
<ServiceId>59182d7e-8874-4d40-bdba-44936bcce815</ServiceId>
<AssemblyName>Services.Test.dll</AssemblyName>
<State>Ready</State>
</Service>
</ArrayOfService>
Assemblies that can be run will implement this interface
public interface IService
{
event EventHandler<ServiceMessageModel> StatusChanged;
string ServiceName { get; set; }
Guid ServiceId { get; set; }
ServiceState State { get; set; }
void Start();
void Stop();
}
For each item in the manifest the app will create an instance of each class and store that reference in a list:
private void LoadServices()
{
_services = new List<IService>();
string[] files = Directory.GetFiles(_servicesLocation, "*.dll");
foreach (string file in files)
{
var assemblyExistsInManifest = _manifest.Where(x => file.Contains(x.AssemblyName)).Any();
if (assemblyExistsInManifest)
{
Assembly assembly = Assembly.LoadFrom(file);
var types = assembly.GetTypes();
foreach (Type type in types)
{
var typeExistsInManifest = _manifest.Where(x => type.ToString().Contains(x.ServiceName)).Any();
var implementsInterface = typeof(IService).IsAssignableFrom(type);
if (typeExistsInManifest && implementsInterface)
var serviceClass = Activator.CreateInstance(type) as IService;
serviceClass.StatusChanged += ServiceClass_StatusChanged;
_services.Add(serviceClass);
}
}
}
}
}
Next, the list is iterated and each service in it is started in its own thread
private void StartAllServices()
{
foreach (var service in _services)
{
Task.Factory.StartNew(() =>
{
service.Start();
});
}
}
This is the basic idea and some code that I already have in place.
Questions
1) Cancelling / Pausing. I need to be able to stop a service from further processing. This could mean the service remains loaded but does not continue processing, or it could mean actually cancelling the task the service is running is so it can be unloaded.
This means that I would need to store separate CancellationTokenSource instances for each service as they're loaded in the StartService method above so that I can call Cancel() on a task for a specific service. If I defined the CancellationTokenSource as a property on the IService interface, then the StartServices method could create the CancellationTokenSource and assign it to the service at the time it is started.
This would allow my CancelService method to look like this
private void CancelService(Guid serviceId)
{
var service = _services.FirstOrDefault(x => x.ServiceId == serviceId);
if (service != null)
{
var ct = service.CancellationToken;
ct.Cancel();
}
}
Any thoughts on this?
2) Error Handling. Assuming an exception happens inside a service, this should not "crash" the service but instead set its State to Error and report that to the Host running on our server. The Windows Service portion should catch exceptions thrown by the services and report that back to the server. At no point should an exception cause either the Windows Service or any service to stop running. Any thoughts on this?
Summary
I'm VERY new to TPL and have little to no experience with it, so this design may be totally wrong. If so, please share your thoughts on a more stable approach. I would also appreciate any example code you may have.
Thank you
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
modified 28-Mar-17 14:42pm.
|
|
|
|
|
Starting the services: I'd prefer to have some kind of thread owned by a class implementing IService. In its Start method, that thread is created and started. Use a try...catch inside the loop of the main method (or in the Timer_Elapsed event, if you use a timer). Start/Stop can be controlled with a boolean member variable _keepRunning - just check it in the loop.
Error Handling: Add an "error event" to IService which gets subscribed by the Windows service. Ideally, it contains some information about how corrupted the state of that service is, such that the main service can decide if it's appropriate to unload it and create a new instance.
|
|
|
|
|
If I understand what you're saying.. it would mean creating the thread and error handling INSIDE the service classes, correct?
If so, it puts the responsibility on individual developers to follow the pattern to make it work.
Classes implementing IService only really need to have some basic info (Id, Name) and Start and Stop methods that the Windows Service can call into.
Am I understanding what you're saying here?
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
Can you provide a small example to illustrate what you're saying here?
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
I'm creating a class instance using Activator.CreateInstance
var serviceClass = Activator.CreateInstance(type) as IInstrumentService;
_services.Add(serviceClass);
Then, later, I start each service. I want to catch any exceptions that occur in the service class. I was thinking about something like
private void StartAllServices()
{
foreach (var service in _services)
{
Task.Factory.StartNew(() =>
{
service.Start();
}).ContinueWith(task =>
{
if (task.Exception != null)
{
}
});
}
}
Any reason this would not work? Know of a better way to do this?
Thanks
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
Hi Kevin,
So does your service have a Stop() method as well? Normally a start method would be kind of asynchronous in nature, kicking off its own threads, opening network listeners and that sort of thing, so the test you have there looks like it would catch exceptions in just that part.
Or is it that Start() method is more of a Run()? By which I means it runs until completion, possibly days later?
A good catch all would be this (lifted from Visual Studio right in front of me):
AppDomain.CurrentDomain.UnhandledException += CurrentDomainUnhandledException;
Regards,
Rob Philpott.
|
|
|
|
|
Yes, the services have a Stop method. The services are independent of each other. They can each do entirely different things.
There will be a schedule in place that each services runs under. One may run only once, while another may run regularly at different days & times.
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
Just a quick note:
Passing a cancellation token to the Task.Factory.StartNew() will give you an external control for your child tasks.
Otherwise I've been playing with the same construct for a component host (except that I hydrate my components via a MEF ImportMany) and it works very well.
"There are three kinds of lies: lies, damned lies and statistics."
- Benjamin Disraeli
|
|
|
|