Visualizzazione dei risultati da 1 a 4 su 4
  1. #1
    Utente di HTML.it L'avatar di dottwatson
    Registrato dal
    Feb 2007
    Messaggi
    3,012

    poker on line ... come iniziare?

    buonasera a tutti.

    Premetto che no nho mai affrontato questo argomento, quindi sono all' oscuro di quelle che possono essere eventuali certificazioni e vincoli di realizzazione.


    Mi è stato chiesto da un cliente di proporre un progetto per quello che riguarda la realizzazione di un poker on line.
    data la nutara del gioco e delle diverse versioni di gioco ho qualche perplessità, nonchè una idea + o - vaga di come gestire i singoli moduli che compongono il sistema.


    tecnologie interessate:

    - Flash/Flex/Air per lanciare il tavolo di gioco (preferito)
    OPPURE
    - .exe da installare in locale




    gestione tavolo:
    -min e max giocatori
    -tipo di gioco (texas, classico ecc..)
    -min e max puntata



    gestione dei $$ :

    - ogni utente ha un conto virtuale dove versa e preleva i $$
    - tutte le transazioni devono essere gestite all' esterno
    - gestione della relazione fish ==> valore reale

    gestione degli utenti
    - non è consentito il gioco su tavoli multipli ma solo 1 alla volta



    questo è pressapoco quello che ho pensato come base iniziale del sistema.

    LE DOMANDE:

    ci sono certificazioni su cui dovrei informarmi?
    come gestire il DB?
    come garantirmi una comunicazione client/server SICURA?


    grazie pe ril supporto

    Mirko
    Non sempre essere l'ultimo è un male... almeno non devi guardarti le spalle

    il mio profilo su PHPClasses e il mio blog laboweb

  2. #2
    Allora, io posso darti un paio di idee, ma, dato che si tratta anche di cose LEGALI, meglio che fai comunque qualche controllo extra:
    1- non so se ho capito bene cosa intendi per "certificazione", ma un paio di cose posso dirti: Pocker Online non è illegale, ma in Italia ha sicuramente bisogno di un permesso per essere legalizzato, soprattutto perché i soldi, sebbene manipolati con fiche virtuali, sono veri. Un'altra cosa che devi vedere sono i marchi registrati, perché, non vorrei dire una ca####a, ma credo che "Pocker Online" sia un trademark.
    2- Il DB non è tanto come gestirlo, ma è il traffico che dovrà gestire, e questa è una questione che non un programmatore, ma un DBA dovrebbe sistemare, vedi dove il tuo cliente vuole installare l'applicazione, fagli presente che se ci sarà una buona affluenza per il DB servirà un server dedicato, ed il resto (clustering, replication, etc) lo deve gestire il SysAdmin o il DBA, tu devi solo pensare alla struttura dello schema del DB e a come il codice si relazionerà ad esso.
    Sullo schema in sè, non credo di poterti dare una mano dato che, mi è sembrato dal tuo discorso, tu hai le idee più chiare di me.
    3- La comunicazione sicura è, da sempre, SSL. Devi acquistare un certificato SSL da una delle authorities, e poi installarlo sul Web Server (anche questo meglio se lo fa il SysAdmin), a quel punto quando punti il browser su https://tuosito.it la comunicazione viene criptata.

    Per il resto non saprei cosa consigliarti, se non di seguire la migliore tradizione dell'UML:
    1- casi d'uso: chi lo usa e che azioni devono fare
    2- attività: dettaglia ciascuna azione e definisci i componenti
    3- classi (o schema): crea l'albero delle strutture della quale la tua Web Application si comporrà (mi riferisco alla Model Part, ovvero al DB ed alle Classi che manipolano i dati, poi potrai passare alla View, cioè alle parte che mostrano i dati)

    Per il resto, se devo dirti cosa usare, credo che Flex o Flash siano la cosa migliore, dato che farlo in Ajax è un delirio come pochi altri.
    A meno che non vuoi pensare proprio ad una applicazione desktop in multitier da distribuire, in questo caso ti raccomanderei di usare .NET, sebbene io lo odi, o Delphi, perché su Windows vanno nativi, a differenza di Java che, sebbene più portata per queste cose, richiede il suo Runtime che non tutti sono disposti, o riescono, ad installarlo.

  3. #3
    Utente di HTML.it L'avatar di dottwatson
    Registrato dal
    Feb 2007
    Messaggi
    3,012
    Originariamente inviato da artorius
    Allora, io posso darti un paio di idee, ma, dato che si tratta anche di cose LEGALI, meglio che fai comunque qualche controllo extra:
    1- non so se ho capito bene cosa intendi per "certificazione", ma un paio di cose posso dirti: Pocker Online non è illegale, ma in Italia ha sicuramente bisogno di un permesso per essere legalizzato, soprattutto perché i soldi, sebbene manipolati con fiche virtuali, sono veri. Un'altra cosa che devi vedere sono i marchi registrati, perché, non vorrei dire una ca####a, ma credo che "Pocker Online" sia un trademark.
    si infatti il titolo era indicativo, il nome non sarà quello. Ed è proprio la legge che entra in vigore la molla che ha attivato il nostro cliente.
    2- Il DB non è tanto come gestirlo, ma è il traffico che dovrà gestire, e questa è una questione che non un programmatore, ma un DBA dovrebbe sistemare, vedi dove il tuo cliente vuole installare l'applicazione, fagli presente che se ci sarà una buona affluenza per il DB servirà un server dedicato, ed il resto (clustering, replication, etc) lo deve gestire il SysAdmin o il DBA, tu devi solo pensare alla struttura dello schema del DB e a come il codice si relazionerà ad esso.
    ed è proprio questo il punto, progettare correttamente il db vuol dire avere o meno delle porte aperte sulla gestione degli utenti e dei tavoli, comprese eventuali modifiche future e/o implementazioni
    Sullo schema in sè, non credo di poterti dare una mano dato che, mi è sembrato dal tuo discorso, tu hai le idee più chiare di me.
    la mia intenzione è quella di dare si uno strumento valido, ma porre anche dei paletti per non fare diventare un sito del genere troppo complesso ma allo stesso tempo funzionale.
    In pratica dire al cliente 'si, ti conviene! NO, è una cosa che è complessa e dispendiosa da gestire in termini economici e di sviluppo'.
    3- La comunicazione sicura è, da sempre, SSL. Devi acquistare un certificato SSL da una delle authorities, e poi installarlo sul Web Server (anche questo meglio se lo fa il SysAdmin), a quel punto quando punti il browser su https://tuosito.it la comunicazione viene criptata.
    non è sufficente... con un ethereal (sniffing della scheda di rete) sarei in grado comunque di vedere tutti i pacchetti che passano, di qualsiasi natura. in SSL o HTTPS

    La crittografia deve essere reversibile ma senza possibilità di rottura se non con una chiave unica o creata secondo i parametri che variano sull' utente.

    Per il resto non saprei cosa consigliarti, se non di seguire la migliore tradizione dell'UML:
    1- casi d'uso: chi lo usa e che azioni devono fare
    2- attività: dettaglia ciascuna azione e definisci i componenti
    3- classi (o schema): crea l'albero delle strutture della quale la tua Web Application si comporrà (mi riferisco alla Model Part, ovvero al DB ed alle Classi che manipolano i dati, poi potrai passare alla View, cioè alle parte che mostrano i dati)
    beh, una cosa del genere ovviamente vuole lo studio di tutto, potendo evitare al massimo la necessita di ripogettare situazioni diverse in corso d' opera... cmq è sempre bene avere una base logica ben fatta, hai fatto bene a dirlo
    Per il resto, se devo dirti cosa usare, credo che Flex o Flash siano la cosa migliore, dato che farlo in Ajax è un delirio come pochi altri.
    A meno che non vuoi pensare proprio ad una applicazione desktop in multitier da distribuire, in questo caso ti raccomanderei di usare .NET, sebbene io lo odi, o Delphi, perché su Windows vanno nativi, a differenza di Java che, sebbene più portata per queste cose, richiede il suo Runtime che non tutti sono disposti, o riescono, ad installarlo.
    effettivamente è così.. un .exe mi limiterebbe al mondo win, mentre Flash/Flex mi darebbe apertura a tutti gli os, senza contare quelli che per motivi professionali o altro non possono installare applicazioni in locale. Mi chiedevo però gli svantaggi e vantaggi tra avere una applicazione locale e tecnologia Adobe: ho visto che molti utilizzano applicazioni da installare in locale... è una scelta psicologica (l' utente si sente piu sicuro vedendo un applicazione che si installa in locale) o pratica?

    grazie intanto per le tue risposte
    Non sempre essere l'ultimo è un male... almeno non devi guardarti le spalle

    il mio profilo su PHPClasses e il mio blog laboweb

  4. #4
    Originariamente inviato da dottwatson
    si infatti il titolo era indicativo, il nome non sarà quello. Ed è proprio la legge che entra in vigore la molla che ha attivato il nostro cliente.
    Ok, questo ha risposto alla mia domanda inespressa...
    ed è proprio questo il punto, progettare correttamente il db vuol dire avere o meno delle porte aperte sulla gestione degli utenti e dei tavoli, comprese eventuali modifiche future e/o implementazioni
    Per questo ti conviene parlarne con un DBA serio.
    la mia intenzione è quella di dare si uno strumento valido, ma porre anche dei paletti per non fare diventare un sito del genere troppo complesso ma allo stesso tempo funzionale.
    In pratica dire al cliente 'si, ti conviene! NO, è una cosa che è complessa e dispendiosa da gestire in termini economici e di sviluppo'.
    ah, ma allora è ancora in fase di studio della fattibilità. Guarda, non dico che non sia fattibile, anche se personalmente ne farei a meno, però devi far presente al cliente che necessitera di non poco lavoro, soprattutto in termini di test.
    non è sufficente... con un ethereal (sniffing della scheda di rete) sarei in grado comunque di vedere tutti i pacchetti che passano, di qualsiasi natura. in SSL o HTTPS
    Il che, IMHO, non ti deve interessare, tu devi assicurare una comunicazione sicura e basta, la sicurezza dagli attacchi è una questione lasciata a chi amministra il server.
    La crittografia deve essere reversibile ma senza possibilità di rottura se non con una chiave unica o creata secondo i parametri che variano sull' utente.
    ...ed SSL fa questo...
    beh, una cosa del genere ovviamente vuole lo studio di tutto, potendo evitare al massimo la necessita di ripogettare situazioni diverse in corso d' opera... cmq è sempre bene avere una base logica ben fatta, hai fatto bene a dirlo
    Partivo dal presupposto che fosse già approvato, e che tu dovessi affrontare questo "terribile" passo. Ma mi pare di capire che, anche di questo, ne sai più di me.
    effettivamente è così.. un .exe mi limiterebbe al mondo win, mentre Flash/Flex mi darebbe apertura a tutti gli os, senza contare quelli che per motivi professionali o altro non possono installare applicazioni in locale. Mi chiedevo però gli svantaggi e vantaggi tra avere una applicazione locale e tecnologia Adobe: ho visto che molti utilizzano applicazioni da installare in locale... è una scelta psicologica (l' utente si sente piu sicuro vedendo un applicazione che si installa in locale) o pratica?
    Sempre IMHO, è una questione di sicurezza legata alla funzionalità: se fai un file .EXE quello farà, in quel modo funzionerà (anche se con Winsozz non si può mai essere sicuri, mi ricordo bene di quando usci XP che quasi niente sviluppato sotto win 98 funzionava), solo su windows vero, ma sarai sicuro che non ci sono problemi. Se, invece, fai una Web App lì non saprai mai se l'utente che la usa ha gli strumenti che tu hai previsto, con la potenza di memoria minima, e potrai solo basarti su ciò che il browser vede (che è poco), quindi dovrai prevedere tutta una serie di possibili scenari che aumenteranno enormemente la mole di lavoro da fare (altra cosa della quale dovrai rendere conto al tuo cliente)

    Guarda, per un applicativo che fa SOLO pocker online credo che valga la pena di sviluppare 2 (o 3 se proprio vuoi fare le cose per bene) versioni una per Windows in .NET o Delphi ed una per MacOS in Objective-C o Java (ed anche, se ne fai 3, una il C o Java per Linux). Se il tuo cliente vuole creare un'azienda di pocker online non è una cattiva idea una cosa simile.

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 © 2025 vBulletin Solutions, Inc. All rights reserved.