Visualizzazione dei risultati da 1 a 6 su 6
  1. #1

    [JAVA] Problema con struttura dati

    Qualcuno di voi ricorda il mio famoso progettino?

    http://www.di.unipi.it/~marcod/Didat.../progetto.html

    Mi sto incasinando con la struttura dati...

    Io ho usato una serie di Vector incapsulati in questo modo

    codice:
    [VectorHost]
     |--[NomeHost][ObjectDirectory]
                   |--[NomeDirectory][ObjectFile]
                                      |--[ListaFile]
                  [ObjectDirectory2]
                   |--[NomeDirectory][ObjectFile]
                  [ObjectDirectory3]
                   |--[NomeDirectory][ObjectFile]
     |--[NomeHost2][ObjectDirectory]
     |--[NomeHost3][ObjectDirectory]
     ...e così via
    Ma questa soluzione ha un inconveniente e due problemi

    1) Quando scambio tra i vari host i dati, devo passare i vari ObjectHost con un nome identificativo... quindi facciamo un esempio... quando io pubblico qualcosa il mio indirizzo IP è 127.0.0.1, ma quando passo questo oggetto a un'altro pc quel 127.0.0.1 dovrà essere sostituito con l'ip reale (es. 192.168.0.45)... beh... male di poco.. devo solo tirare fuori il nomeHost e sostituirlo... un po' laborioso ma efficace.

    2) Il secondo è un problema di gestione... es.. se in Linux cerco di pubblicare tutto il contenuto della directory "/" mi da un errore di Out Of Memory.. anche qui il male non è grosso... non credo che qualcuno voglia condividere tutti i file del proprio computer.

    3) L'ultimo ma non ultimo problema accade se cancello una directory... ammettiamo che pubblichi una directory

    /usr/share/fabrizio

    Automaticamente verranno inserite anche tutte le sottodirectory presenti... es.

    /usr/share/fabrizio/java
    /usr/share/fabrizio/immagini

    Ora ammettiamo che pubblichi anche la directory

    /usr/share

    Se io rimuovo la directory /usr/share/fabrizio, in realtà tale directory e le sue sottodirectory devono essere ancora accessibili, perchè sottodirectory di /usr/share, quindi come eliminare /usr/share/fabrizio?

    se rimuovo quella e le sue sottodir, se ho pubblicata una "sopradirectory" mi ritrovo a non poter più accedere a directory che in realtà sono accessibili.
    E il discorso vale anche al contrario... se rimuovessi /usr/share, e come metodo utilizzassi "elimina tutte le dir che cominciano con", rischierei di rimuovere la directory /usr/share/fabrizio (e relative sottodir) che in realta sono ancora condivise e quindi devono essere accessibili!


    Ed ora arrivano le domande...

    1) Esiste una struttura dati che mi risolva il problema 2? quello della memoria?
    2) E' tanto sbagliata l'idea di usare dei refer, ovvero un terzo campo (String) che indichi "chi" ha inserito tale directory? in questo modo quando voglio rimuovere una directory deve rimuovere solo quelle che hanno tale directory come refer!


    Lo so che è incasinato... pensate a me che ci sto lavorando su... quanto mi ci sto intrippando!!!


    Cmq, Buon Anno!
    [Homepage] [Contattami]
    Powered by: Ubuntu - Debian - Gentoo
    Developing: Java - C++ - PHP

    [supersaibal]"Perchè tanto Debian è meglio"
    [/supersaibal]

  2. #2
    Utente di HTML.it
    Registrato dal
    Mar 2002
    Messaggi
    315
    Il progetto e' interessante.

    1) Se stai lavorando sotto linux e per trovare l'indirizzo IP della macchina usi getLocalHost() sappi che e' un bug della JVM.
    Infatti sotto linux come primo indirizzo restituisce sempre 127.0.0.1, anche se la macchina e' dotata di scheda di rete attiva. Questo per dire che anche quando pubblichi qualcosa il tuo indirizzo non e' 127.0.0.1, ma l'indirizzo di rete (ad esempio 192.168.0.XXX).

    2)Come hai gia' visto e' impossibile far pubblicare "/" perche' significherebbe trasmettere tuttoi li proprio HD, giga e giga di roba.
    Potresti fare un controllo e avvisare l'utente che cio' non e' possibile.
    Una alternativa possibile potrebbe essere creare le sottodirectory del primo livello e cominciare a riempire solo un ramo del fs.
    Ad esempio se uno volesse publicare "/" tu memorizzi solo le directory. E poi ne gestisci una sola alla volta
    codice:
    "/"
     +-- "/bin"
     +-- "/sbin"
     +-- "/home"
     +-- "/root"
     +-- "/boot"
     +-- "/usr"
          +-- "local"
          +... eccetera
    Quindi nel server scrivi solo i percorsi delle prime sottodirectory, tranne una, che e' quella che cominci a riempire, nell' esempio "/usr/local"
    Questo metodo ti permetterebbe di funzionare anche in caso in cui una sottodirectory fosse troppo grande per poter gestire il tutto in un colpo solo.

    3) Non ho ben capito quale sia il tuo problema: se pubblichi "/usr/share/fabrizio/giochi" e poi anche
    "/usr/share/fabrizio"
    e decidi di togliere la prima, non vedo quale sia il problema, e' come se tu cancellassi solo "giochi", non e' detto che la sopradirectory ne imponga la vita perpetua mentre se cancelli la sopradirectory trovo giusto che venga eliminata anche "giochi".
    L'utilizzo del campo refer potrebbe essere interessanta, magari potresti includere un file di testo all'interno di ogni dir, contenente il nome e l'indirizzo IP del proprietario della dir.
    Ciao,
    Lorenzo

  3. #3
    Originariamente inviato da lelefante
    Il progetto e' interessante.

    1) Se stai lavorando sotto linux e per trovare l'indirizzo IP della macchina usi getLocalHost() sappi che e' un bug della JVM.
    Infatti sotto linux come primo indirizzo restituisce sempre 127.0.0.1, anche se la macchina e' dotata di scheda di rete attiva. Questo per dire che anche quando pubblichi qualcosa il tuo indirizzo non e' 127.0.0.1, ma l'indirizzo di rete (ad esempio 192.168.0.XXX).
    Lo so.. è per questo che chi riceverà l'oggetto dovrà sostituire il 127.0.0.1 contenente nell'oggetto con l'indirizzo IP "reale" dell'host che ha inviato l'oggetto! Mi lamentavo solo del fatto che è una cosa noiosa...

    2)Come hai gia' visto e' impossibile far pubblicare "/" perche' significherebbe trasmettere tuttoi li proprio HD, giga e giga di roba.
    Potresti fare un controllo e avvisare l'utente che cio' non e' possibile.
    Una alternativa possibile potrebbe essere creare le sottodirectory del primo livello e cominciare a riempire solo un ramo del fs.
    Ad esempio se uno volesse publicare "/" tu memorizzi solo le directory. E poi ne gestisci una sola alla volta
    codice:
    "/"
     +-- "/bin"
     +-- "/sbin"
     +-- "/home"
     +-- "/root"
     +-- "/boot"
     +-- "/usr"
          +-- "local"
          +... eccetera
    Quindi nel server scrivi solo i percorsi delle prime sottodirectory, tranne una, che e' quella che cominci a riempire, nell' esempio "/usr/local"
    Questo metodo ti permetterebbe di funzionare anche in caso in cui una sottodirectory fosse troppo grande per poter gestire il tutto in un colpo solo.
    Il discorso qui è problematico... perchè far vedere il contenuto di una dir "su richiesta", considerando il fatto che vengono aggiornati via UDP creerebbe un bel problema di "sincronizzazione" nel rendere sempre disponibile il contenuto "in remoto" di una dir... Mi sa che cercherò l'eccezione adatta... e se uno gli da una dir troppo grande, beh catturo l'eccezione e gli dico che non si può fare

    3) Non ho ben capito quale sia il tuo problema: se pubblichi "/usr/share/fabrizio/giochi" e poi anche
    "/usr/share/fabrizio"
    e decidi di togliere la prima, non vedo quale sia il problema, e' come se tu cancellassi solo "giochi", non e' detto che la sopradirectory ne imponga la vita perpetua mentre se cancelli la sopradirectory trovo giusto che venga eliminata anche "giochi".
    L'utilizzo del campo refer potrebbe essere interessanta, magari potresti includere un file di testo all'interno di ogni dir, contenente il nome e l'indirizzo IP del proprietario della dir.
    Del "proprietario" non me ne frega nulla... il referer mi serve per eliminare "solo" le sottodirectory pubblicate come conseguenza nella pubblicazione di una dir.
    Il problema è che ogni directory pubblicata (e relative sottodir) deve avere vita a se' come se si trattasse di directory differenti


    PS: qualcuno ha qualche idea su una possibile struttura dati che non sia un incapsulamento di vector? Qualcosa di più veloce o più performante?
    [Homepage] [Contattami]
    Powered by: Ubuntu - Debian - Gentoo
    Developing: Java - C++ - PHP

    [supersaibal]"Perchè tanto Debian è meglio"
    [/supersaibal]

  4. #4
    ho risolto il punto 3...

    ecco come deve venire l'applicazione da console (manca ancora il discovery UDP)
    Immagini allegate Immagini allegate
    [Homepage] [Contattami]
    Powered by: Ubuntu - Debian - Gentoo
    Developing: Java - C++ - PHP

    [supersaibal]"Perchè tanto Debian è meglio"
    [/supersaibal]

  5. #5
    ed eccovi la preview di come sarà l'applicazione tramite server web...
    in pratica fa le stesse cose della console, solo attraverso delle semplici pagine html!

    :metallica :metallica :metallica
    Immagini allegate Immagini allegate
    [Homepage] [Contattami]
    Powered by: Ubuntu - Debian - Gentoo
    Developing: Java - C++ - PHP

    [supersaibal]"Perchè tanto Debian è meglio"
    [/supersaibal]

  6. #6
    Ma.. per una cosa del genere non e` meglio un classico albero o un grafo?

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2024 vBulletin Solutions, Inc. All rights reserved.