# Requests über ein Socket



## jacquipre79 (4. Jul 2007)

Hallo,

ich hatte vor einigen Tagen schon mal einen Thread eröffnet, aber leider keine Antwort erhalten. Nun habe ich ein ähnliches Problem.

Es ist so, dass wir hier einen Webserver entwickelt haben, der Requests des Browsers (IE) empfängt und diese über jeweils eine Connection (Socket) via Servlets beantwortet. Der Socket wird anschließend geschlossen. Das Problem ist, dass dieses Neuaufbauen von Verbindungen und Schließen dieser zu Performance-Problemen geführt hat. Deshalb jetzt die Idee, eine Verbindung für mehrere Requests offen zu halten. Ich habe das soweit versucht, zu implementieren. In meinem Testbeispiel werden nun nicht mehr 8 Verbindungen geöffnet, also so:

```
Request A (Connection 1)
Request B (Connection 2)
Request C (Connection 3)
Request D (Connection 4)
Request E (Connection 5)
Request F (Connection 6)
Request G (Connection 7)
Request H (Connection 8)
```

Stattdessen werden jetzt 2 Verbindungen geöffnet, was ich nicht ganz verstehe, weil ich - so denke ich - den Code so geschrieben habe, dass nur eine Verbindung entstehen soll. Im Moment sieht das also so aus:



```
Request A  (Connection 1)
Request B (Connection 1)
----- Request C (Connection 2)
Request D (Connection 1)
----- Request E (Connection 2)
Request F (Connection 1)
----- Request G (Connection 2)
Request H  (Connection 1)
```

Habt ihr eine Ahnung woran das liegen könnte?

Hier mal Auszüge aus dem Code zum besseren Verständnis:

Server Klasse

```
while (this.isRunning()) {
try {
    socket = serverSocket.accept();
    synchronized (socket) 
    {
           MyConnection connection = new MyConnection(this, socket);                        
           Thread thread = new Thread(connections, connection, "DEBUG_" + counter );
           counter++;
           thread.setDaemon(true);
...
    }
}
```

MyConnection - run()

```
try
{
while(true)
{
     if (socket == null || socket.isClosed()) break;
 
     line = in.readLine();
     if (line == null)  break;
     else if (!readFirstLine && (line.trim().length() > 0))
     {
	// parse the first Header line
	boolean ok = parseFirstHeaderLine(line);
	if (!ok) break;
	readFirstLine = true;
		                		
     }
     // read header values and add to header map
    else if (line.trim().length() > 0)
   {
	int colonPos = line.indexOf(":");
        if (colonPos > 0) 
        {
                String key = line.substring(0, colonPos);
                String value = line.substring(colonPos + 1);
                headers.put(key, value.trim());			
         }
     }
     else
     {
	         checkForPostRequest();
		 // process request (search servlet and send response)
		 processRequest();
		                		
		 // request ends, a new request will start
		 readFirstLine = false;
		 headers.clear();
		 requestParameters.clear();
	}
		                	
}
}
catch(IOException e)
{
...
}
finally
{
// close socket
}
```

Für Hinweise oder Hilfe wäre ich wirklich sehr dankbar.

jacquipre


----------



## kleiner_held (4. Jul 2007)

Das Oeffnen der Verbindungen geht vom Browser aus - da kannst du nicht verhindern, dass der unter Umstaenden eine zweite Verbindung aufmacht.

PS: eine Mischung aus eigenem SocketServer und Servlets ist nunja sehr exotisch


----------



## tuxedo (4. Jul 2007)

Aber eigentlich sollte doch das öffnen und schließen von Sockets recht fix gehen... Wie stark ist der Server denn frequentiert?

- Alex


----------



## jacquipre79 (4. Jul 2007)

kleiner_held hat gesagt.:
			
		

> Das Oeffnen der Verbindungen geht vom Browser aus - da kannst du nicht verhindern, dass der unter Umstaenden eine zweite Verbindung aufmacht.



Aha, aber der Code sieht richtig aus? Ich habe da nichts falsch gemacht? Der Browser macht das also eher zufällig...? 



			
				kleiner_held hat gesagt.:
			
		

> PS: eine Mischung aus eigenem SocketServer und Servlets ist nunja sehr exotisch



Das kann wohl sein, aber die Firma, für die ich arbeite, brauchte nun mal einen eigenen Webserver für eigene Implementierungen (auch eigener Servlets). Das lässt sich nicht ändern und funktioniert auch wunderbar...

Danke


----------



## Guest (4. Jul 2007)

alex0801 hat gesagt.:
			
		

> Aber eigentlich sollte doch das öffnen und schließen von Sockets recht fix gehen... Wie stark ist der Server denn frequentiert?
> 
> - Alex



Das Problem ist, dass einige Kunden mit VPN arbeiten und das Schließen der Sockets zu Verbindungsabbrüchen führte. Deshalb wurde ein SocketLinger mit 100 Sekunden für jeden Socket gesetzt, was das VPN-Problem beseitigte, aber gleichzeitig dazu führte, dass das Schließen der Sockets länger dauert. D.h., um eine bestimmte Aktion clientseitig auszuführen, z.b. Auswahl eines Elementes aus einer Dropdownliste, wurden mehrere Sockets geöffnet und geschlossen (jeweils mit SocketLinger), so dass diese Anforderung fast 3 Sekunden lang ist. Also viel zu lang


----------



## tuxedo (4. Jul 2007)

Hmm, ich kenne keine Socket-Verbindung die eine VPN-Verbindung dermaßen beeinflusst dass sie abgerochen wird.

Ich habe schonm mit PPTP und IPSec (Cisco VPN) gearbeitet. Und wenn man das als VPN betrachten kann: Via SSH getunnelte Socketverbindungen.

Es gab, bis auf den Cisco VPN-Client, der in allen meinen Java-Programmen (und auch manche andere Programme, beispielsweise Du-Meter) NaN Fehler hervorgebracht hat, nie derartige Probleme.

Ich denke der Fehler ist beim VPN zu suchen und nicht am Java-Code.

Was ich aber auch nicht so ganz verstehe: Entkoppel doch das Schließen des Sockets mit einem Thread.. Das bremst die Anwendung dann nicht. Und in nem Thread isses dann wurscht ob der 3sek braucht oder nicht...

Ist generell etwas "ungeschickt" eine Anwendung vom Netzwerk abhängig zu machen. Ich mein was die GUI und Wartezeiten im Netzwerk betrifft.

- Alex


----------



## jacquipre79 (5. Jul 2007)

alex0801 hat gesagt.:
			
		

> Hmm, ich kenne keine Socket-Verbindung die eine VPN-Verbindung dermaßen beeinflusst dass sie abgerochen wird.


Naja, so richtig abgebrochen wird sie durch VPN nicht, nur werden die Daten nicht vollständig gesendet, d.h. wenn die Response gesendet wurde, wurde der Socket schon geschlossen, aber es kam halt noch vor, dass einige Pakete noch "unterwegs" waren. Deshalb mußte der SocketLinger eingebaut werden. Ich bin auch später zu dem Projekt zugestoßen, dass ich die genauen, detaillierten Gründe nicht kenne, sondern nur generell weiß, warum das so gemacht wurde. Also sorry, wenn ich mich da etwas ungenau oder mißverständlich ausgedrückt habe.

Das, was ich jetzt teste, passiert ganz unabhängig von einem VPN. Mittlerweile habe ich gelesen, dass der Internet Explorer maximal 2 Persistent Connections aufbaut, d.h. dies würde ja meinem Szenario entsprechen. Ich vermute einfach, dass ich - wie kleiner_held schon meinte - keinen Einfluss darauf habe, wieviele Connections der Client (also IE) öffnet. Ich kann mir aber sicher sein, dass es max. nur 2 werden. Im tcpTrace sehe ich dann auch diese 2 Verbindungen mit Status "connected". Wenn keine weiteren Requests mehr vom Client kommen, dann werden diese Verbindungen nach einem Timeout geschlossen; der IE hat dafür standardmäßig 60 Sekunden vorgesehen. So die Theorie... Oder weiß jemand mehr?


----------



## tuxedo (5. Jul 2007)

Naja, wie gesagt:

Netzwerke sollten ein Programm nicht lahmlegen können. Sowas sollte man entsprechend mit Threads entkoppeln.


----------

