---

Hejsa,

Jeg sidder og roder med lidt socket programmering. Jeg har lavet en client
og en server der kan accepterer at flere clienter connecter til den.

Det funker sådan set fint, men hvordan kan serveren se om en client
connection stadig er aktiv. Man kan jo ikke altid sikre at clienten siger
pænt farvel (o:

vh
Dahl

---

"Dahl" <[NOSPAM]jimmichr@hotmail.com[NOSPAM]> wrote in message
news:a0j3vn$2eg8$1@news.cybercity.dk...
> Hejsa,
>
> Jeg sidder og roder med lidt socket programmering. Jeg har lavet en client
> og en server der kan accepterer at flere clienter connecter til den.
>
> Det funker sådan set fint, men hvordan kan serveren se om en client
> connection stadig er aktiv. Man kan jo ikke altid sikre at clienten siger
> pænt farvel (o:

Det kan den faktisk heller ikke!
En connection dør først i det du skriver til den/læser fra den og den
failer.
Derfor kan du typisk risikere at du har nogle "zombie" connections som er
i live, indtil du skriver til dem.
Spørgsmålet er så hvordan man vil takle disse zombie connections - typisk
vil man lave client/server pinge hinanden efter et givet interval.
*Jeg* kan ikke umiddelbart komme i tanke om en bedre måde...

Hvordan vil folk takle dette problem ud over at pinge?

/Brian Matzon

---

Skod skod skod, det var ikke lige det jeg ville høre (o: Jeg håber andre kan
komme med en smartere løsning.

Sagen er nemlig den at protokollen mellem client og server er en simple
client-spørger server-svarer kommunikation. Dvs at serveren aldrig sender
noget til clienten af fri vilje, og det vil derfor være at komplicere både
server og specielt clienten at implementere ping-pong kommandoer i
protokollen.

Min bedste løsning nu er at serveren altid betragter en client connection
som død hvis den ikke har modtaget en kommando indenfor et bestemt
tidsinterval (f.eks. 10 minutter). Det vil funke men det er jo bestemt ikke
på den "fede" måde

Håber på andre ideer...

vh
Dahl

"Brian Matzon" <brian@matzon.dk> wrote in message
news:3c2d1b59$0$55612$edfadb0f@dspool01.news.tele.dk...
> "Dahl" <[NOSPAM]jimmichr@hotmail.com[NOSPAM]> wrote in message
> news:a0j3vn$2eg8$1@news.cybercity.dk...
> > Hejsa,
> >
> > Jeg sidder og roder med lidt socket programmering. Jeg har lavet en
client
> > og en server der kan accepterer at flere clienter connecter til den.
> >
> > Det funker sådan set fint, men hvordan kan serveren se om en client
> > connection stadig er aktiv. Man kan jo ikke altid sikre at clienten
siger
> > pænt farvel (o:
>
> Det kan den faktisk heller ikke!
> En connection dør først i det du skriver til den/læser fra den og den
> failer.
> Derfor kan du typisk risikere at du har nogle "zombie" connections som er
> i live, indtil du skriver til dem.
> Spørgsmålet er så hvordan man vil takle disse zombie connections - typisk
> vil man lave client/server pinge hinanden efter et givet interval.
> *Jeg* kan ikke umiddelbart komme i tanke om en bedre måde...
>
> Hvordan vil folk takle dette problem ud over at pinge?
>
> /Brian Matzon
>
>
>

---

Din løsning er klassisk. Det kaldes en keep-alive message, og tjener kun det
formål, at lade serveren vide, at klienten stadig lever.

Internet servere med session-data såsom ASP og JSP/Servlet har samme
problematik. For sidstnævnte sætter man et max-interval og hvis serveren
ikke hører fra klienten inden for dette tidsrum, dør sessionen - jeg antager
at ASP har noget tilsvarende.


Med venlig hilsen / best regards

Soeren Dalby



"Dahl" <[NOSPAM]jimmichr@hotmail.com[NOSPAM]> wrote in message
news:a0j9et$2oot$1@news.cybercity.dk...
> Skod skod skod, det var ikke lige det jeg ville høre (o: Jeg håber andre
kan
> komme med en smartere løsning.
>
> Sagen er nemlig den at protokollen mellem client og server er en simple
> client-spørger server-svarer kommunikation. Dvs at serveren aldrig sender
> noget til clienten af fri vilje, og det vil derfor være at komplicere både
> server og specielt clienten at implementere ping-pong kommandoer i
> protokollen.
>
> Min bedste løsning nu er at serveren altid betragter en client connection
> som død hvis den ikke har modtaget en kommando indenfor et bestemt
> tidsinterval (f.eks. 10 minutter). Det vil funke men det er jo bestemt
ikke
> på den "fede" måde
>
> Håber på andre ideer...
>
> vh
> Dahl
>
> "Brian Matzon" <brian@matzon.dk> wrote in message
> news:3c2d1b59$0$55612$edfadb0f@dspool01.news.tele.dk...
> > "Dahl" <[NOSPAM]jimmichr@hotmail.com[NOSPAM]> wrote in message
> > news:a0j3vn$2eg8$1@news.cybercity.dk...
> > > Hejsa,
> > >
> > > Jeg sidder og roder med lidt socket programmering. Jeg har lavet en
> client
> > > og en server der kan accepterer at flere clienter connecter til den.
> > >
> > > Det funker sådan set fint, men hvordan kan serveren se om en client
> > > connection stadig er aktiv. Man kan jo ikke altid sikre at clienten
> siger
> > > pænt farvel (o:
> >
> > Det kan den faktisk heller ikke!
> > En connection dør først i det du skriver til den/læser fra den og den
> > failer.
> > Derfor kan du typisk risikere at du har nogle "zombie" connections som
er
> > i live, indtil du skriver til dem.
> > Spørgsmålet er så hvordan man vil takle disse zombie connections -
typisk
> > vil man lave client/server pinge hinanden efter et givet interval.
> > *Jeg* kan ikke umiddelbart komme i tanke om en bedre måde...
> >
> > Hvordan vil folk takle dette problem ud over at pinge?
> >
> > /Brian Matzon
> >
> >
> >
>
>

---

Dahl wrote:

> Skod skod skod, det var ikke lige det jeg ville høre (o: Jeg håber andre kan
> komme med en smartere løsning.
>
> Sagen er nemlig den at protokollen mellem client og server er en simple
> client-spørger server-svarer kommunikation. Dvs at serveren aldrig sender
> noget til clienten af fri vilje, og det vil derfor være at komplicere både
> server og specielt clienten at implementere ping-pong kommandoer i
> protokollen.
>
> Min bedste løsning nu er at serveren altid betragter en client connection
> som død hvis den ikke har modtaget en kommando indenfor et bestemt
> tidsinterval (f.eks. 10 minutter). Det vil funke men det er jo bestemt ikke
> på den "fede" måde


Sådan virker HTTP også. Som udgangspunkt lukkes forbindelsen lige efter
serveren er færdig med at svare.

Hvis klienten veder om det kan forbindelsen holdes åben i en nærmere
angivet periode, som serveren selvfølgelig selv kan vælge om den vil
leve op til. Klienten skal så, hvis den vil holde forbindelsen åben,
sørge for at forny tidsfristen inden den løber ud.

-dennis

---

Ok tak for svarene,

Af anden årsag besluttede jeg at bruge kommunikere med objects mellem client
og server ved brug af ObjectOutputStream og ObjectInputStream og her bliver
der faktisk kastet af exception af ObjectInputStream.readObject() hvis
socket forbindelsen er død.

Dahl

"Dennis Thrysøe" <dt@netnord.dk> wrote in message
news:3C2E0EE6.8050709@netnord.dk...
> Dahl wrote:
>
> > Skod skod skod, det var ikke lige det jeg ville høre (o: Jeg håber andre
kan
> > komme med en smartere løsning.
> >
> > Sagen er nemlig den at protokollen mellem client og server er en simple
> > client-spørger server-svarer kommunikation. Dvs at serveren aldrig
sender
> > noget til clienten af fri vilje, og det vil derfor være at komplicere
både
> > server og specielt clienten at implementere ping-pong kommandoer i
> > protokollen.
> >
> > Min bedste løsning nu er at serveren altid betragter en client
connection
> > som død hvis den ikke har modtaget en kommando indenfor et bestemt
> > tidsinterval (f.eks. 10 minutter). Det vil funke men det er jo bestemt
ikke
> > på den "fede" måde
>
>
> Sådan virker HTTP også. Som udgangspunkt lukkes forbindelsen lige efter
> serveren er færdig med at svare.
>
> Hvis klienten veder om det kan forbindelsen holdes åben i en nærmere
> angivet periode, som serveren selvfølgelig selv kan vælge om den vil
> leve op til. Klienten skal så, hvis den vil holde forbindelsen åben,
> sørge for at forny tidsfristen inden den løber ud.
>
> -dennis
>

---

Interessant - jeg mente ellers bestemt at HTTP var session-løs. Hvad betyder
det at have en HTTP session ??

For serverside programmer er det jo rart at kunne have tilstande og andre
data gemt for en brugersession, men hvad kan HTTP gemme på tværs af kald for
samme session ??


--
Med venlig hilsen / best regards

Soeren Dalby

"Dennis Thrysøe" <dt@netnord.dk> wrote in message
news:3C2E0EE6.8050709@netnord.dk...
> Dahl wrote:
>
> > Skod skod skod, det var ikke lige det jeg ville høre (o: Jeg håber andre
kan
> > komme med en smartere løsning.
> >
> > Sagen er nemlig den at protokollen mellem client og server er en simple
> > client-spørger server-svarer kommunikation. Dvs at serveren aldrig
sender
> > noget til clienten af fri vilje, og det vil derfor være at komplicere
både
> > server og specielt clienten at implementere ping-pong kommandoer i
> > protokollen.
> >
> > Min bedste løsning nu er at serveren altid betragter en client
connection
> > som død hvis den ikke har modtaget en kommando indenfor et bestemt
> > tidsinterval (f.eks. 10 minutter). Det vil funke men det er jo bestemt
ikke
> > på den "fede" måde
>
>
> Sådan virker HTTP også. Som udgangspunkt lukkes forbindelsen lige efter
> serveren er færdig med at svare.
>
> Hvis klienten veder om det kan forbindelsen holdes åben i en nærmere
> angivet periode, som serveren selvfølgelig selv kan vælge om den vil
> leve op til. Klienten skal så, hvis den vil holde forbindelsen åben,
> sørge for at forny tidsfristen inden den løber ud.
>
> -dennis
>

---

Soeren Dalby wrote:

> Interessant - jeg mente ellers bestemt at HTTP var session-løs. Hvad betyder
> det at have en HTTP session ??
>
> For serverside programmer er det jo rart at kunne have tilstande og andre
> data gemt for en brugersession, men hvad kan HTTP gemme på tværs af kald for
> samme session ??

Når man snakker om HTTP sessions er det ikke på connection niveau. HTTP
er ganske rigtigt stateless, men mange servere simulerer sessions ved at
give en cookie til browseren, som den sender med til alle fremtidige
requests.

Denne cookie kan så bruges til at genkende 'sessionen'. Serveren har så
mulighed for at time en session ud, når den er træt af at vente på en
klients næste request.

Hvis ikke klienten understøtter cookies, kan man også bruge argumenter i
URL'en kombineret med 'URL rewriting'. Det vil sige at sørge for, at
ALLE links rundt omkring (hvis vi snakker HTML) skal indeholde f.eks.
?JSESSIONID=76fds76dsf76fd76dsf76fds.

-dennis

---

On Sat, 29 Dec 2001 01:56:32 +0100, "Dahl" <[NOSPAM]jimmichr@hotmail.com[NOSPAM]> wrote:

>Hejsa,
>
>Jeg sidder og roder med lidt socket programmering. Jeg har lavet en client
>og en server der kan accepterer at flere clienter connecter til den.
>
>Det funker sådan set fint, men hvordan kan serveren se om en client
>connection stadig er aktiv. Man kan jo ikke altid sikre at clienten siger
>pænt farvel (o:
>
Baseres kommunikationen på TCP (og ikke UDP), ligger det underliggende ping-pong i netværksprotokollen, og serverens registering af
clienten nedlukning af forbindelse, er i Java f.eks implementeret sådan at der kastes en IOException fra ObjectInputStream.readObject();

Følgende lille server, venter på en string fra en connectende client, og giver en (fjollet) string tilbage. Når clienten lukker
forbindelsen, afslutter serverthread's run() metode.

import java.io.*;
import java.net.*;

public class Server {

   public Server()
   {
         
      System.out.println("Starting server");
      int threadNum = 1;
      try {
         ServerSocket server = new ServerSocket( 5000, 100 );
      
         while ( true ) {
            // hænger indtil en klient connecter på port 5000, og starter derefter en thread
            new TCPSessionThread(server.accept(), threadNum++).start();
         }
      }
      catch ( IOException io ) {
         // accept throws
         io.printStackTrace();
         System.exit(0);
      }
   }

   public static void main( String args[] )
   {
      System.out.println("Starting server");
      Server app = new Server();
   }
}

class TCPSessionThread extends Thread
{
   ObjectOutputStream output;
   ObjectInputStream input;
   Socket connection;
   private int tn;
   
   TCPSessionThread(Socket argConnection, int threadNum) {
      connection = argConnection;
      tn = threadNum;
      
   }
   
   public void run() {
      try {
         output = new ObjectOutputStream(connection.getOutputStream() );
         output.flush();
         input = new ObjectInputStream(connection.getInputStream() );
         System.out.println( "connection established in thread "+tn);
         String message;
         
         while (true) {
            try {
               message = (String) input.readObject();
               if (message.toLowerCase().equals("andrei"))
                  sendString("Jeg snakker med en brevdue");
               else if (message.toLowerCase().equals("susanne"))
                  sendString("Jeg snakker med rigtig høne");
               else   
                  sendString("Jeg snakker med en anonymous rex");
            }
            catch(ClassNotFoundException ccnfex) {
                System.out.println("class not fond exception" );
             }
            catch(IOException ioex) {
               System.out.println("Connection lost in thread "+tn);
               break;
            }
         }
         output.close();
         input.close();
         connection.close();
      }
      catch(IOException ex) {
         ex.printStackTrace();
         System.exit(1);
      }
      
   }
   private void sendString( String s )
   {
      try {
         output.writeObject(s);
         output.flush();
      }
      catch ( IOException cnfex ) {
         System.out.println("Error writing object" );
      }
   }

}

   
MVH
Benny Andersen

---

Men hvad nu, hvis maskinen crasher eller programmet tvinges til at stoppe
via en kill ea. Kan man da også være sikker på, at streamen reagerer på
samme måde ??


--
Med venlig hilsen / best regards

Soeren Dalby

"Benny Andersen" <be99@worldonline.dk> wrote in message
news:3c2e1cf7.32553789@news.worldonline.dk...
> On Sat, 29 Dec 2001 01:56:32 +0100, "Dahl"
<[NOSPAM]jimmichr@hotmail.com[NOSPAM]> wrote:
>
> >Hejsa,
> >
> >Jeg sidder og roder med lidt socket programmering. Jeg har lavet en
client
> >og en server der kan accepterer at flere clienter connecter til den.
> >
> >Det funker sådan set fint, men hvordan kan serveren se om en client
> >connection stadig er aktiv. Man kan jo ikke altid sikre at clienten siger
> >pænt farvel (o:
> >
> Baseres kommunikationen på TCP (og ikke UDP), ligger det underliggende
ping-pong i netværksprotokollen, og serverens registering af
> clienten nedlukning af forbindelse, er i Java f.eks implementeret sådan at
der kastes en IOException fra ObjectInputStream.readObject();
>
> Følgende lille server, venter på en string fra en connectende client, og
giver en (fjollet) string tilbage. Når clienten lukker
> forbindelsen, afslutter serverthread's run() metode.
>
> import java.io.*;
> import java.net.*;
>
> public class Server {
>
> public Server()
> {
>
> System.out.println("Starting server");
> int threadNum = 1;
> try {
> ServerSocket server = new ServerSocket( 5000, 100 );
>
> while ( true ) {
> // hænger indtil en klient connecter på port 5000, og starter derefter en
thread
> new TCPSessionThread(server.accept(), threadNum++).start();
> }
> }
> catch ( IOException io ) {
> // accept throws
> io.printStackTrace();
> System.exit(0);
> }
> }
>
> public static void main( String args[] )
> {
> System.out.println("Starting server");
> Server app = new Server();
> }
> }
>
> class TCPSessionThread extends Thread
> {
> ObjectOutputStream output;
> ObjectInputStream input;
> Socket connection;
> private int tn;
>
> TCPSessionThread(Socket argConnection, int threadNum) {
> connection = argConnection;
> tn = threadNum;
>
> }
>
> public void run() {
> try {
> output = new ObjectOutputStream(connection.getOutputStream() );
> output.flush();
> input = new ObjectInputStream(connection.getInputStream() );
> System.out.println( "connection established in thread "+tn);
> String message;
>
> while (true) {
> try {
> message = (String) input.readObject();
> if (message.toLowerCase().equals("andrei"))
> sendString("Jeg snakker med en brevdue");
> else if (message.toLowerCase().equals("susanne"))
> sendString("Jeg snakker med rigtig høne");
> else
> sendString("Jeg snakker med en anonymous rex");
> }
> catch(ClassNotFoundException ccnfex) {
> System.out.println("class not fond exception" );
> }
> catch(IOException ioex) {
> System.out.println("Connection lost in thread "+tn);
> break;
> }
> }
> output.close();
> input.close();
> connection.close();
> }
> catch(IOException ex) {
> ex.printStackTrace();
> System.exit(1);
> }
>
> }
> private void sendString( String s )
> {
> try {
> output.writeObject(s);
> output.flush();
> }
> catch ( IOException cnfex ) {
> System.out.println("Error writing object" );
> }
> }
>
> }
>
>
> MVH
> Benny Andersen

---

On Sun, 30 Dec 2001 19:02:25 +0100, "Soeren Dalby" <nospam@nospam.com> wrote:

>Men hvad nu, hvis maskinen crasher eller programmet tvinges til at stoppe
>via en kill ea. Kan man da også være sikker på, at streamen reagerer på
>samme måde ??
<CUT>
Tænker du på hvis clienten cracher? IOException giver ingen diffentiering mellem 'pænt farvel' og nedlukning af andre årsager. Hvis der er
behov for det, kan man vel lave en protocol, hvor klienten f.eks sender en 'bye' string før afslutning.
Hvis Serveren cracher, kastes der en IOException hos clienten, når socket forbindelsen søges anvendt til kommunikation.

MVH Benny Andersen

---

"Benny Andersen" <be99@worldonline.dk> wrote in message
news:3c2e1cf7.32553789@news.worldonline.dk...
> Baseres kommunikationen på TCP (og ikke UDP), ligger det underliggende
ping-pong i netværksprotokollen, og serverens registering af
> clienten nedlukning af forbindelse, er i Java f.eks implementeret sådan at
der kastes en IOException fra ObjectInputStream.readObject();
<SNIP>
Men så antager du også at det er tovejs kommunikation. Hvad nu når det er en
monolog, hvor serveren
sender beskeder til klienten hvert 15 time, hvordan kan den så vide om en
connection er i live, andet end
hvert 15 time?

/Brian Matzon

---

On Sun, 30 Dec 2001 22:25:31 +0100, "Brian Matzon" <brian@matzon.dk> wrote:

>
>"Benny Andersen" <be99@worldonline.dk> wrote in message
>news:3c2e1cf7.32553789@news.worldonline.dk...
>> Baseres kommunikationen på TCP (og ikke UDP), ligger det underliggende
>ping-pong i netværksprotokollen, og serverens registering af
>> clienten nedlukning af forbindelse, er i Java f.eks implementeret sådan at
>der kastes en IOException fra ObjectInputStream.readObject();
><SNIP>
>Men så antager du også at det er tovejs kommunikation. Hvad nu når det er en
>monolog, hvor serveren
>sender beskeder til klienten hvert 15 time, hvordan kan den så vide om en
>connection er i live, andet end
>hvert 15 time?
Der er den kommunikation som man har fastlagt i protokollen, og den kan være tovejs. Men man kan kun vide om begge parter er der ved at
bruge den, så ja, prøver man hvert 15. minut får man på det tidspunkt vished.
>
>/Brian Matzon
>
En TCP forbindelse (ikke at forveksel med HTTP protokolen) er en pålidelig forbindelse, hvor begge parter kan sende (og modtage).
Klient/Server rollerne eksisterer TCP forbindelsesmæssigt kun i forbindelsesfasen, hvor serveren lytter på en bestemt port(her port 5000):
   ServerSocket server = new ServerSocket( 5000, 100 )
   server.accept(); // hænger intil en klient kalder

Og klienten kalder på denne port (her localhost, port 5000)
   Socket client = new Socket(InetAddress.getByName( "127.0.0.1" ), 5000 );
   // Sender hermed også source port, så serveren kan kende forskel på klienter.

Forbindelsen er oprettet intil enten klienten eller serveren kalder close() metoden på Socket objektet. Sålænge forbindelsen er oprettet kan
det registreres hvis modparten forsvinder. (Ved forsøg på at kommunikere over Socket)

Som også Jacob Bunk Nielsen er inde på, er en HTTP session, en forbindelse som disconnectes efter hvert 'response'. Der er ingen klient at
kalde når først forbindelse er lukket, for klienten lytter ikke til nogen port.
Hvis man f.eks ønsker at anvende en browser som frontend til noget serverside administration, og serveren skal kunne connecte, stikker man
browseren en applet med nogen server funktionalitet i.

MVH
Benny Andersen

---

"Soeren Dalby" <nospam@nospam.com> writes:

> Interessant - jeg mente ellers bestemt at HTTP var session-løs.

HTTP er ganske rigtig stateless.

Men nyere servere og browsere kan finde ud af at kaste flere
forskellige HTTP-requests igennem en enkelt TCP-forbindelse ved at
sende en:

Connection: Keep-Alive

HTTP-header.

> Hvad betyder det at have en HTTP session ??

At man opretter en TCP-forbindelse, sender en HTTP-kommando (GET,
POST, PUT, whatever), får svar og at serveren derefter lukker
forbindelsen.

--
Jacob - www.bunk.cc
It'll be a nice world if they ever get it finished.

---

Jacob Bunk Nielsen <spam@bunk.cc> writes:

> > Interessant - jeg mente ellers bestemt at HTTP var session-løs.
>
> HTTP er ganske rigtig stateless.
>
> Men nyere servere og browsere kan finde ud af at kaste flere
> forskellige HTTP-requests igennem en enkelt TCP-forbindelse ved at
> sende en:
>
> Connection: Keep-Alive

Normalt er det nok at bare at lave et gyldigt HTTP/1.1 request.
F.eks.:
GET / HTTP/1.1\r\n
Host:\r\n
\r\n
Så bliver man ved med at sende requests indtil serveren sender en
Connection: close
header eller man selv gør. Derefter kan man ikke regne med at
forbindelsen er åben længere. Serveren kan dog også vælge at time
forbindelse ud hvis man har været inaktiv for længe, typisk ca 20
sekunder. HTTP/1.1 giver enddog mulighed for at pipeline sine request,
sådan at man ikke behøver at vente på svar på hvert eneste request man
sender, før man sender det næste, dette kan øge datagennemstrømningen
dramatisk og belaster webserveren mindre.
Alt om HTTP-protokollen kan iøvrigt læses i RFC2616.

--
Christian Hemmingsen