How To: BinaryReader BinaryWriter

Guardando fra le statistiche ho notato che qualcuno ha visitato il mio blog per individuare un metodo anche banale per mascherare quello che si scrive...

Va da se che l'utilità di questo gesto può essere legittima sempre ed in qualsiasi momento, il più è organizzarsi bene.

L'idea di utilizzare un BinaryReader e BinaryWriter può essere un inizio ma non è detto che assolva a quanto si desidere fare..

Tanto più è complesso l'algoritmo di "criptografia ..." perchè al nocciolo è di questo che si sta parlando tanto più complesso sarà per i "curiosoni" beccare quello che stiamo scrivendo..

Il mio consiglio, è di utilizzare più livelli, e logiche differenti, e soprattutto di non utilizzare mai la stessa.  Va da se che se qualcuno trova l'eseguibile che crea lo stream.. ha anche in mano il processo per cui leggere quello che state "criptando".

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.IO;


namespace BinaryTextFile
{
    class Program
    {
        static void Main(string[] args)
        {
            //
            // esempio di scrittura binaria
            //
            FileStream fs = new FileStream(@"c:\demo.txt", FileMode.Create);
            BinaryWriter bw = new BinaryWriter(fs);
            bw.Write("numeri\r\n");
            bw.Write(123);
            bw.Write(123.4);
            bw.Write("\r\nTesto\r\n");
            bw.Write("io sarò in chiaro");
            bw.Write("\r\nBolean\r\n");
            bw.Write(false);
            bw.Close();

            //
            // questo esempio tuttavia non 
            // ci consente di nascondere del tutto il 
            // contenuto del nostro file
            // tuttavia ci consente di scoprire 
            // che i numeri puf vengono 
            // convertiti...
            //

            FileStream fs2 = new FileStream(@"c:\demo2.txt", 
                    FileMode.Create);
            BinaryWriter bw2 = new BinaryWriter(fs2);

            string s = "questa è una splendida demo";

            for (int i = 0; i < s.Length; i++)
            {
                bw2.Write(Convert.ToByte(s[i]));
            }

            bw2.Close();

            FileStream fs3 = new FileStream(@"c:\demo2.txt", 
                    FileMode.Open);
            BinaryReader br = new BinaryReader(fs3);
            string s1 = "";
            int p = 0;

            while (p < br.BaseStream.Length)
            {
                s1 += Convert.ToChar(br.ReadByte()).ToString();
                p++;
            }
            br.Close();

            //
            // tuttavia questo implica che 
            // si deve sapere che cosa si 
            // sta leggendo
            //

            Console.WriteLine(s1);

            Console.ReadLine();
        }
    }

} 

Questo esempio pur limitato in quello che avviene da un minimo di garazia... ma naturalmente è solo un banale esempio...

Singleton not immutable....

che tradotto è ... chi mi cambia il singleton da sotto le chiappe ?

Generalemte se abbiamo scritto il codice per bene, questa cosa non avviene, tuttavia potebbe succedere se e solo abbiamo commesso qualche leggerezza nella gestione della classe singleton.

Questo esempio mostra come un metodo "creato appositamente" crei un effetto davvero indesiderato.

    public class SingleInstance
    {
        private static iInstance itx = null;

        public static iInstance getInstance()
        {         
            if (SingleInstance.itx == null)
            {
                itx = new Original();
                return  itx;
            }

            return itx;            
        }

        public static void ChangeInstance()
        {            
            SingleInstance.itx = new Mock();
        }
    }

Questi i miei due oggetti che rappresenteranno il singleton

    public interface iInstance
    {
        string DoGetValue();
    }

    public class Original : iInstance
    {
        private string _value = "Orginal";
        public string DoGetValue()
        {
           return _value;
        }

    }

    public class Mock : iInstance
    {
        private string _value = "Mock";
        public string DoGetValue()
        {
           return _value;
        }
    }

Quessto è il metodo che utilizzo per effettuare il test.
Dal settimo elemento modifichiamo il nostro singleton..

        private void btnStart_Click(object sender, EventArgs e)
        {
            string v = "";

           
            for (int i = 0; i < 15; i++)
            {             
                v = Singleton.SingleInstance.getInstance().DoGetValue();

                lstEvents.Items.Add("s[" + i.ToString() + "]:" + v);
                lstEvents.Refresh();

                Thread.Sleep(100);

                if (i == 7)
                {
                    // Simuliamo 
                    // che qualcuno ci cambi le 
                    // carte in tavola 
                    Singleton.SingleInstance.ChangeInstance();
                }
            }
        } 

Morale in

v = Singleton.SingleInstance.getInstance().DoGetValue()

Ottengo il valore "original" fino a quando non cambio il contenuto del mio singleton..
Una variazione sul tema ... che a tutti gli effetti rende immutabile il singleton potrebbe essere questa...

Singleton.iInstance ist = Singleton.SingleInstance.getInstance();

...

... 

v = ist.DoGetValue();

L'implicazione è che l'istanza rimarrebbe strettamente legata ad una variabile senza dover mai essere reistanziata...

La secelta giusta ??? la prima ma se e solo se nessuno ti cambia da il naso il valore del singleton stesso.

Sincronizzazione

Sull'argomento ci sono svariati modelli di implementazione e di contro anche svariati algoritmi più o meno complessi in base anche al tipo di sincronizzazione che vogliamo
effettuare. In molti casi questo tipo di pratica può essere banalmente svolta tramite uno script dos schedulato, tuttavia non si ha il pieno controllo della struttura.

Quello che mi serve e quello che rappresenterò non è altro che un sottoinsieme della mia reale necessità, e più schematicamente è rappresentabile secondo quanto segue:
a) Monitoraggio continuo,
b) Copia specifica di cartelle / file
c) Esecuzione di attività server side propedeutiche alla sincronizzazione.
d) Log delle attività
e) bassa o assente iterazione utente

A fronte di questi brevi requisiti, non è difficile intuire che il tutto sarà reso tramite un servizio, depositato sulla macchina che chiameremo host B. La macchina host A
potrebbe essere interpretata come il pc o device con i sorgenti.




A fronte di questi brevi requisiti, non è difficile intuire che il tutto sarà reso tramite un servizio, depositato sulla macchina che chiameremo host B. La macchina host A
potrebbe essere interpretata come il pc o device con i sorgenti.


Ciò detto l'atto in se della sincronizzazione è rappresentato con un banale File.Copy, il più e comprendere come e cosa copiare.

public partial class beeSyncro : ServiceBase
{
    FileSystemWatcher fsw;

    string deployM = @"C:\Users\f.arosio\Deploy_Master";
    string deployS = @"C:\Users\f.arosio\Deploy_Slave";

    string dLog = @"C:\Users\f.arosio\LogFile";

    public beeSyncro()
    {
        InitializeComponent();
        
    }

    protected override void OnStart(string[] args)
    {
        fsw = new FileSystemWatcher();

        fsw.Path = deployM;
        fsw.Filter = "*.dll";
        fsw.IncludeSubdirectories = true;
        fsw.NotifyFilter = NotifyFilters.FileName |
                NotifyFilters.LastWrite | 
                NotifyFilters.CreationTime | 
                NotifyFilters.Size;

        fsw.Created += new FileSystemEventHandler(
                fsw_Created
                );
                        
        fsw.EnableRaisingEvents = true;
        DoWirteLog("Start");
    }

    void fsw_Created(object sender, FileSystemEventArgs e)
    {
        DoWirteLog("Now Copy :" +e.FullPath);
        try
        {
            File.Copy(deployM + @"\" + e.Name, 
            deployS + @"\" + e.Name,true);
        }
        catch (Exception ex)
        {
            DoWirteLog("Copy Failed:" 
            + e.FullPath +" " + 
            ex.Message.ToString().Replace("\r\n",""));
        }
    }

    protected override void OnStop()
    {
        fsw = null;
        DoWirteLog("Stop");
    }

    protected void DoWirteLog(string message)
    {
        TextWriter tw = new StreamWriter(dLog
            +@"\log.log",true);

        tw.WriteLine(DateTime.Now.ToShortDateString() 
            +"|" +DateTime.Now.ToLongTimeString() 
            +"|"+ message);
        tw.Close();
        tw = null;        
    }               
} 

In breve questo è il sorgente che rappresenta il nostro "caso".  Il punto di interesse è dato proprio del FileSystemWatcher, che di suo riesce notificare l'avvenuto cambiamento di una risorsa senza consumeare eccessive risorse di sistema Naturalmente non si sta faecendo ragionamento alcuno su quali file è necessario&nbsp

void fsw_Created(object sender, FileSystemEventArgs e)
{
    DoWirteLog("Now Copy :" +e.FullPath);
    try
    {
        File.Copy(deployM + @"\" + e.Name, 
        deployS + @"\" + e.Name,true);
    }
    catch (Exception ex)
    {
        DoWirteLog("Copy Failed:" 
        + e.FullPath +" " + 
        ex.Message.ToString().Replace("\r\n",""));
    }
}

Questo è il punto , dove possiamo inserire la nostra logica nel caso "si avesse" la necessità di aggiungere granularità al nostro "ben misero Algoritmo".