Visualizzazione dei risultati da 1 a 5 su 5
  1. #1
    Utente di HTML.it
    Registrato dal
    Jan 2002
    Messaggi
    428

    [java] sincronizzare server - client

    Sera,
    vorrei sapere come è strutturata un'applicazione server/client.
    Mi spiego meglio ... per quanto ne so, per far interagire le due applicazioni è necessario metterle in comunicazione tramite i socket e se non ho capito male si possono scambiare informazioni mediante la serializzazione dei dati.
    La cosa che mi lascia più perplesso è la sincronizzazione dei client con il server.
    Le soluzioni dovrebbero essere due, ogni volta che avviene qualcosa è il server a contattare i client ... oppure viceversa sono i client che ad intervalli regolari interrogano il server (polling?!).
    Fino a quì ho detto cose corrette?!
    Spero .. comunque andando avanti ... ora, se per esempio l'applicazione sviluppata è una chat, non è strettamente necessario un frequente refresh, ma in caso di altri tipi di applicazioni come per esempio dei giochi (anche molto elementari) basati su tempo, o azioni (colpire la palla ..etc..) come mi devo comportare? Impostare un bassimo tempo di refresh per ottenere le nuove informazioni? Avendo molti client che fanno molte richieste al server, non pregiudico le prestazioni di quest'ultimo?

    Voi come suggerite di affrontare tale problema?

    grazie
    ciao
    gnegno

  2. #2
    Utente di HTML.it
    Registrato dal
    Feb 2003
    Messaggi
    698

    Re: [java] sincronizzare server - client

    Sera,
    vorrei sapere come è strutturata un'applicazione server/client.
    In generale, è quella architettura per cui esistono due entità: la prima (client) che è progettata per richiedere servizi alla seconda (server), che riceve le richieste le elabora e fornisce una risposta.


    Mi spiego meglio ... per quanto ne so, per far interagire le due applicazioni è necessario metterle in comunicazione tramite i socket e se non ho capito male si possono scambiare informazioni mediante la serializzazione dei dati.
    Qui non c'entra strettamente la serializzazione: tu puoi mettere in comunicazione due macchine utilizzando i socket, come dici giustamente tu. Puoi vederli come un canale di comunicazione in cui si possono scambiare dati (byte) che poi una volta riassemblati insieme possono rappresentare quello che ti pare (una stringa, un file di testo, un video etcetc).

    La cosa che mi lascia più perplesso è la sincronizzazione dei client con il server.
    Le soluzioni dovrebbero essere due, ogni volta che avviene qualcosa è il server a contattare i client ... oppure viceversa sono i client che ad intervalli regolari interrogano il server (polling?!).
    In generale, è il client che fa una richiesta, che il server elabora e rispedisce al mittente. Ma poi tutto dipende dal tipo di 'server'...un server web riceve ed interpreta messaggi http, un server ftp riceve ed interpreta comandi ftp, il server di un videogioco vattelapesca probabilmente notifica tutti i client collegati in quel momento di ogni azione che viene effettuata...eccetera.


    Fino a quì ho detto cose corrette?!
    Spero .. comunque andando avanti ... ora, se per esempio l'applicazione sviluppata è una chat, non è strettamente necessario un frequente refresh, ma in caso di altri tipi di applicazioni come per esempio dei giochi (anche molto elementari) basati su tempo, o azioni (colpire la palla ..etc..) come mi devo comportare? Impostare un bassimo tempo di refresh per ottenere le nuove informazioni?
    Quello che tu chiami refresh è un concetto che è legato strettamente al tipo di applicazione. Nell'esempio della chat, potrebbe corrispondere al momento in cui un client invia un messaggio:
    diciamo che tizio e caio sono nella chat, tizio invia un messaggio al server che lo spedisce a caio, che si vede la chat 'refreshata', quindi in questo caso dal punto di vista di caio è il server a prendere 'l'iniziativa'.
    Dipende dal funzionamento specifico di questa applicazione e ogni volta va studiato caso per caso.

    Penso di non dire una vaccata se dico che in generale il server invia nuovi dati ai client ogni volta che sia necessario renderli noti ai client stessi.

    Avendo molti client che fanno molte richieste al server, non pregiudico le prestazioni di quest'ultimo?
    Voi come suggerite di affrontare tale problema?
    Purtroppo se dei dati devono essere inviati c'e' poco da fare..puoi cercare di ottimizzare le prestazioni ma il discorso rimane strettamente legato alla banda disponibile.
    Anche grossi apparati basati sulla comunicazione di rete possono subire un collasso in caso di una utenza esagerata.

    Io ti suggerisco di chiarirti un po le idee iniziando a dare una guardata alla pila internet e approfondendo il protocollo tcp/ip.
    Poi studi qualcosina su Socket e ServerSocket visto che sei in ambito java, e poi vedrai che ti si spalancheranno diverse porte


  3. #3
    Utente di HTML.it
    Registrato dal
    Jan 2002
    Messaggi
    428
    in generale, è quella architettura per cui esistono due entità: la prima (client) che è progettata per richiedere servizi alla seconda (server), che riceve le richieste le elabora e fornisce una risposta.
    Beh sì .. fino a quà c'ero, per struttura intendevo più all'organizzazione, mi sono espresso male!

    Quello che tu chiami refresh è un concetto che è legato strettamente al tipo di applicazione. Nell'esempio della chat, potrebbe corrispondere al momento in cui un client invia un messaggio:
    diciamo che tizio e caio sono nella chat, tizio invia un messaggio al server che lo spedisce a caio, che si vede la chat 'refreshata', quindi in questo caso dal punto di vista di caio è il server a prendere 'l'iniziativa'.
    Dipende dal funzionamento specifico di questa applicazione e ogni volta va studiato caso per caso.

    Penso di non dire una vaccata se dico che in generale il server invia nuovi dati ai client ogni volta che sia necessario renderli noti ai client stessi.
    Per refresh alludevo all'aggiornamento dei dati.
    Per il caso della chat concordo. Ma in un applicazione in cui il lag deve essere quasi annientato, per esempio una simulazione sportiva (calcio, boxe ...) dove gli aggiornamenti sul comportamento dell'utente devono essere notificati in tempo reale ... è solo una questione di banda?
    Cioè, non so se mi sto spiegando bene e si capisce dov'è il mio dubbio!

    Sicuramente darò un'occhiata a come è strutturata la rete!

    grazie
    ciao

  4. #4
    Utente di HTML.it
    Registrato dal
    Feb 2003
    Messaggi
    698
    Nel tuo esempio specifico non so dirti perchè non ho mai affronatato un progettone tipo un gioco di calcio on line

    Ad ogni modo, il server deve informare i client ogni volta che avviene un cambiamento. Nell'esempio del calcio probabilmente farei una cosa del tipo:
    se un giocatore fa una mossa (tira, sposta un calciatore etc) la invia al server che la spara in broadcast agli altri

    se l'arbitro fischia la fine del primo tempo (situazione indipendente da mosse dei client): il server invia in broadcast l'info di fine tempo

    eccetera

    Questa chiaramente è solo una mia idea che tratta il problema superficialmente e per sommi capi e alle 4 di mattina e anche un po alticcio lol

    comunque non puoi mai prescindere dal fatto che se una certa informazione è necessaria allo svolgimento del gioco questa deve necessariamente essere inviata, anche a costo di appesantire la trasmissione

    ti ripeto che a mio modo di vedere puoi ottimizzare il software quanto ti pare ma rimani sempre legato indissolubilmente alla quantità di banda disponibile, ti basti pensare che un network enorme come battlenet se provi a giocare con un modem 56k lagghi in maniera ingiocabile 8 volte su 10

  5. #5
    Utente di HTML.it
    Registrato dal
    Jan 2002
    Messaggi
    428
    il gioco del calcio era un'esempio, perchè ci sono molti movimenti e in tempi brevissimi ... ma potrebbe essere un gioco di macchine o altro.
    In altri,magari come dama, scacchi o simili, puoi avere molto più lag fra una mossa e l'altra .. però se tiri sù un server che deve permettere di giocare a più utenti .. ai tante info da mandare... boh .. non lo so.. resto un po perplesso comunque

    comunque grazie per le risposte!

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.