Autor Beitrag
Frolo
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic star
Beiträge: 48



BeitragVerfasst: Fr 13.09.13 19:45 
Hey,

ich bin derzeit dabei ein Programm zu schreiben, welches den Datenaustausch innerhalb eines Netzwerkes stark vereinfachen soll. (binäre Daten und Text) Außerdem möchte ich auch eine Live-Bildschirmübertragung einbauen und eine Möglichkeit die Maus zu steuern. Ich habe mit dem Protokoll schon des Öfteren gearbeitet, habe aber ein gewisses Konzeptproblem und zwar: Würdet ihr das alles über einen Port laufen lassen? Ich könnte ja einfach (wenn ich mit Indy arbeiten sollte) mehrere TCP Server auf jeweils andere Ports legen, aber macht man das so? Sozusagen einen zum Screenshots übertragen, den anderen für Befehle, usw. Habt ihr hier eventuell Anregungen für ein Konzept? Wie setze ich das am besten um?

PS: Einzeln bin ich durchaus i der Lage das umzuetzen, binäre Daten senden und auch Texte sind ja kein Problem. Das Problem, das ich habe ist, dass alles gleichzeitig passieren kann :) danke!

Auch ist hierbei natürlich die Frage: Ist TCP das richtige Protokoll (oder vllt besser HTTP, UDP?)
>M@steR<
ontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic starofftopic star
Beiträge: 288
Erhaltene Danke: 3



BeitragVerfasst: Fr 13.09.13 23:55 
Hey Frolo,

ich frage mich zwar, warum du ein Programm schreiben willst was es mindestens schon 100 mal gibt, aber egal. :wink:
Also ich sehe das so:
Schau dir erst mal folgenden Link deiner Konkurrenz an: www.teamviewer.com/d...iewer-verwendet.aspx
Dort stehen die klaren Vorteile wenn du nur einen Port (HTTP 80) verwendest. Nämlich weniger Probleme mit Firewalls usw. Der Nachteil ist das HTTP nicht so flott ist wie TCP oder gar UDP. (scheint aber kein Problem zu sein)
Es gibt jedoch einen Grund warum man mehrere Ports verwendet: (wie z.B. bei FTP, bei dem es einen Daten und einen Befehls Port gibt)
Es ist einfacher. ;-)
Wenn du nur einen Port verwendest musst du dich darum kümmern das die Pakete nicht zu groß sind. Sonst wird die Leitung blockiert und die Gegenseite kann nicht mehr auf befehle reagieren.
Du musst jedoch nicht unbedingt mehrere Ports verwenden, du kannst auch mehrere Clientverbindungen auf demselben Port aufmachen. Ist aber schwieriger dafür ein Protokoll zu schreiben.

Die Entscheidung liegt also ganz bei dir und deinen Anforderungen.

PS: Wenn du dir nen Monat Programmierarbeit ersparen willst: Den VNC Client kann man meine ich auch in seinen eigenen Delphi Programmen einbinden.


Zuletzt bearbeitet von >M@steR< am Mo 16.09.13 03:23, insgesamt 1-mal bearbeitet
Frolo Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic star
Beiträge: 48



BeitragVerfasst: Sa 14.09.13 10:14 
Hey,

erstmal vielen Dank! Aber um zu verstehen, wie Programme funktionieren ist es glaube ich eine gute Möglichkeit sie zu schreiben. Außerdem bin ich überzeugt, dass es dieses in der Form sicher noch nicht gibt. Ich bin 17 Jahre alt und mache das als Hobby. Also :)

Ich habe mich mit einem HTTP Server noch nie wirklich auseinander gesetzt, sollte aber ja kein Problem darstellen. Was ich mich jetzt frage ist: Was passiert, wenn ein anderes Programm (die gleiche Idee hatte und) Port 80 schon benutzt (zB Teamviewer). Kann ich diesen dann überhaupt nutzen? Und Chats bzw Datenübertragung on großen Paketen sollte ich dann über TCP (andere Ports) laufen lassen oder?
Narses
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic star
Administrator
Beiträge: 10181
Erhaltene Danke: 1254

W10ent
TP3 .. D7pro .. D10.2CE
BeitragVerfasst: Sa 14.09.13 13:19 
Moin!

user profile icon>M@steR< hat folgendes geschrieben Zum zitierten Posting springen:
Der Nachteil ist das HTTP nicht so flott ist wie TCP oder gar UDP.
Ach Leute, wenn ich sowas lese... :roll:

Ich weiß nicht, woher das Märchen kommt, dass TCP langsamer als UDP sei, aber es ist definitiv ein Märchen. TCP hat üblicherweise den Nagle-Algorithmus aktiviert, was unter bestimmten Umständen wie eine Verzögerung wirkt. Aber der Datendurchsatz von TCP und UDP unterscheidet sich nicht, da der Overhead, den TCP im IP-Stack ggü. UDP verursacht, auf praktisch jeder Übertragungsstrecke nicht ins Gewicht fallen kann (ne CPU ist einfach so viel schneller, als ein physikalischer Transfer). :idea: Dann kommen noch die TCP-Timeouts hinzu, die fälschlicherweise immer wieder als gefühlt langsam wahrgenommen werden, aber was bitte hat das Protokolltiming mit Datendurchsatz zu tun?! :?!?:

Und zu HTTP: das ist ein Protokoll, dass auf TCP-Verbindungen aufsetzt. :suspect: Vielleicht mal vorher lesen, bevor man das in so eine Vergleichskette wie da oben rein setzt... :?

cu
Narses

_________________
There are 10 types of people - those who understand binary and those who don´t.

Für diesen Beitrag haben gedankt: Martok, Mathematiker
Frolo Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic star
Beiträge: 48



BeitragVerfasst: Sa 14.09.13 13:35 
Danke, aber das klärt mein Problem nicht ganz:

Mehrere Ports (einer für Befehle, einer für [auch große "bis zu 100MB"] Daten) oder einer für alles? Das Problem, was sich mir auch stellt ist die Firewall, da es in 2 Schulen verwendet werden soll. Bei der einen gibts einfach keine Firewall, da ist das einfacher, bei der anderen kommt aber ne Windows Meldung (normale Windows Firewall halt), bei der man Adminrechte braucht, die Schüler ja nicht haben. Gibt es da ne Möglichkeit das zu umgehen? Denn bei mir kommt diese Sicherheitsabfrage auch, wenn ich nen HTTP Server auf Port 80 schalte. Ich meine es soll lediglich die Kommunikation erleichtern.. :D
IhopeonlyReader
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic star
Beiträge: 600
Erhaltene Danke: 23


Delphi 7 PE
BeitragVerfasst: Sa 14.09.13 13:48 
naja dass TCP langsamer ist sagen viele, da bei UDP einfach geschickt wird, bei TCP aber "kontrollliert" auf timeout gewartet etc. wird. Falls das paket nicht ankommt, wird es nochmal geschickt ..
dadurch ist es angeblich "langsamer", natürlich ist es das auch wen man 1GB schickt. Nur am ende sind auf der anderen Seite bei TCP auch 1 GB da! bei UDP eher weniger, mit viel Glück vielleicht alles, aber nochnichtmal unbedingt in der richtigen Reihenfolge....

Datenpakete (engl. packets): sind max. 64KiB groß (wurde mir mal erzählt :D )

Wie du mehrere Sachen über 1 Port machst?
So:
Du schickst z.B. eine Datei
ausblenden volle Höhe Delphi-Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:
31:
32:
33:
34:
35:
var S, S2: TStream;
    aByte: Byte;
    filename: String;
    aBiggerVar: Cardinal;
begin
//normalerweise würdest du denke ich mal das so machen
S := TFileStreamStream.create( deinPfadzurDatei, fmOpenRead or fmShareDenyWrite );
try
 DeinClient.Socket.SendStream( S );
except //da bei erfolg sendstream den Stream freigibt
 S.Free;
end;

//so nun musst du aber "identifizieren" können was du da sendest!
//aber erstmal nen Stream erstellen:
S2 := TMemoryStream.create;
try
aByte := 02//02 wäre dann deine identifizierungsnummer für eine Datei ! (du weißt ab jetzt folgt: Dateigröße, Dateinamenlänge, Dateiname, Datei selbst
S2.WriteBuffer( aByte, 1 );
S := TFileStreamStream.create( deinPfadzurDatei, fmOpenRead or fmShareDenyWrite ); //Datei öffnen
aBiggerVar := S.Size;
S2.WriteBuffer( aBiggerVar, 4 );
Filename := copy( deinPfadzurDatei, length( ExtractFilePath(deinPfadzurDatei) )+1, length(deinPfadzurDatei) - length( ExtractFilePath(deinPfadzurDatei) ) );
aBiggerVar := length( Filename );
S2.WriteBuffer( aBiggerVar, 4 );
S2.WriteBuffer( Pointer(Filename)^, aBiggerVar * SizeOF(Char) );
S.Seek( 0, soFromBeginning );
S2.CopyFrom( S, S.Size );
S.Free;
DeinClient.Socket.SendStream( S2 );
except
if Assigned(S) then
  S.Free;
S2.Free;
end;


(Code wurde verwendet, da Delphi-Quelltext als normaler Text angezeigt wurde :()

Wichtig dabei ist, dass du die Identifizierung einbaust, und ebenso bei variablen größen (wie bei Dateien oder Strings) die Größe mit angibst !

_________________
Sucht "neueres" Delphi :D
Wer nicht brauch was er hat, brauch auch nicht was er nicht hat!


Zuletzt bearbeitet von IhopeonlyReader am Sa 14.09.13 20:16, insgesamt 2-mal bearbeitet
>M@steR<
ontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic starofftopic star
Beiträge: 288
Erhaltene Danke: 3



BeitragVerfasst: Sa 14.09.13 18:05 
user profile iconNarses hat folgendes geschrieben Zum zitierten Posting springen:
Ich weiß nicht, woher das Märchen kommt, dass TCP langsamer als UDP sei

Ja, da hast du Recht, ich habe Äpfel mit Birnen verglichen. Es kommt wohl sehr darauf an was für Daten man sendet. Wenn man nur 1 Byte verschicken möchte könnte das mit UDP schneller gehen (wenn das Paket durchkommt) als mit TCP. Ich würde dennoch niemals den Komfort von TCP dafür aufgeben. :wink:

Dass das HTTP Protokoll auf dem TCP Protokoll aufbaut ist mir durchaus bewusst. Genau daher nehme ich meine Vermutung das HTTP langsamer ist als TCP (ich habe es nie gemessen), da die Bytes die für das HTTP Protokoll benötigt werden mit über die TCP Verbindung geschickt werden müssen. Klar macht das bei DSL 150Mibs nicht viel aus. Genau aus diesem Grund habe ich ja oben geschrieben dass es scheinbar kein Problem zu sein scheint. Bei einer Modem Verbindung müsste das nach ein paar Hunderttausend Paketen jedoch auffallen, oder?

@Frolo:
Teamviewer macht das so, dass der Server immer bei Denen läuft. Somit müssen beide Parteien nur eine Clientverbindung zum Server aufbauen. Der Server gibt die Pakete quasi nur weiter. Auf diesem Prinzip bauen die meisten Anwendungen auf. Der Nachteil für dich bei diesem Prinzip ist, das du einen Server zu Verfügung stellen musst.

user profile iconFrolo hat folgendes geschrieben Zum zitierten Posting springen:
Was passiert, wenn ein anderes Programm (die gleiche Idee hatte und) Port 80 schon benutzt (zB Teamviewer).

Wie gesagt, Teamviewer macht keinen Server auf deinem PC auf, sondern verbindet sich nur zu dem Teamviewer Server.
jaenicke
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starofftopic star
Beiträge: 19272
Erhaltene Danke: 1740

W11 x64 (Chrome, Edge)
Delphi 11 Pro, Oxygene, C# (VS 2022), JS/HTML, Java (NB), PHP, Lazarus
BeitragVerfasst: Sa 14.09.13 21:31 
user profile icon>M@steR< hat folgendes geschrieben Zum zitierten Posting springen:
@Frolo:
Teamviewer macht das so, dass der Server immer bei Denen läuft. Somit müssen beide Parteien nur eine Clientverbindung zum Server aufbauen. Der Server gibt die Pakete quasi nur weiter.
Das stimmt so nicht. Einerseits kann man auch direkt verbinden, wenn der zu steuernde PC direkt erreichbar ist, andererseits dient der Server auch im Normalfall nur als Vermittler der Verbindung. Die Pakete laufen danach dann nicht über den Server.
Bekannt ist die Technik als Hole Punching und wird von vielen Programmen verwendet.

Für diesen Beitrag haben gedankt: >M@steR<
Mr_Emre_D
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starofftopic star
Beiträge: 114
Erhaltene Danke: 14



BeitragVerfasst: So 15.09.13 15:21 
user profile iconNarses hat folgendes geschrieben Zum zitierten Posting springen:
Moin!

user profile icon>M@steR< hat folgendes geschrieben Zum zitierten Posting springen:
Der Nachteil ist das HTTP nicht so flott ist wie TCP oder gar UDP.
Ach Leute, wenn ich sowas lese... :roll:

Ich weiß nicht, woher das Märchen kommt, dass TCP langsamer als UDP sei, aber es ist definitiv ein Märchen. TCP hat üblicherweise den Nagle-Algorithmus aktiviert, was unter bestimmten Umständen wie eine Verzögerung wirkt. Aber der Datendurchsatz von TCP und UDP unterscheidet sich nicht, da der Overhead, den TCP im IP-Stack ggü. UDP verursacht, auf praktisch jeder Übertragungsstrecke nicht ins Gewicht fallen kann (ne CPU ist einfach so viel schneller, als ein physikalischer Transfer). :idea: Dann kommen noch die TCP-Timeouts hinzu, die fälschlicherweise immer wieder als gefühlt langsam wahrgenommen werden, aber was bitte hat das Protokolltiming mit Datendurchsatz zu tun?! :?!?:

Und zu HTTP: das ist ein Protokoll, dass auf TCP-Verbindungen aufsetzt. :suspect: Vielleicht mal vorher lesen, bevor man das in so eine Vergleichskette wie da oben rein setzt... :?

cu
Narses


Dankeschön, dass du mir die Arbeit abgenommen hast xD...
Gefährliches Halbwissen gehört ausgerottet!
IhopeonlyReader
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic star
Beiträge: 600
Erhaltene Danke: 23


Delphi 7 PE
BeitragVerfasst: So 15.09.13 16:05 
mal so nebenbei, wie lässt sich der Nagle-Algorithmus bei TServersocket/TClientsocket abstellen?

_________________
Sucht "neueres" Delphi :D
Wer nicht brauch was er hat, brauch auch nicht was er nicht hat!
jaenicke
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starofftopic star
Beiträge: 19272
Erhaltene Danke: 1740

W11 x64 (Chrome, Edge)
Delphi 11 Pro, Oxygene, C# (VS 2022), JS/HTML, Java (NB), PHP, Lazarus
BeitragVerfasst: So 15.09.13 16:56 
Bei Indy (das wir immer nutzen, die Socket-Komponenten sind ja schon ewig als veraltet markiert und aktuellen Delphis standardmäßig nicht mehr aktiv) gibt es einfach UseNagle.

Bei den Sockets such mal nach TCP_NODELAY, wie man die Option dort setzt, weiß ich nicht.
Mr_Emre_D
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starofftopic star
Beiträge: 114
Erhaltene Danke: 14



BeitragVerfasst: So 15.09.13 17:06 
user profile iconIhopeonlyReader hat folgendes geschrieben Zum zitierten Posting springen:
mal so nebenbei, wie lässt sich der Nagle-Algorithmus bei TServersocket/TClientsocket abstellen?


www.entwickler-ecke....ewtopic.php?t=111918
Such hier nach TCP_NODELAY