Mein System ist dabei zwar ein wenig schlechter als der, der beim Raknet-Test
verwendet wurde, doch ist der Unterschied in der Leistung vernachlässigbar gering.
Nun gut, Raknet verwendet UDP während ich TCP verwende.
TCP ist zwar nicht so schnell wie UDP, doch ein solch ernormer Unterschied
entsteht doch nicht einfach so (oder stimmt diese Proportion etwa? Also dass man bei UDP 25 000 hinbekommt wenn man bei TCP um die 2000 hat?, kenne ich ma nicht so gut aus)

Meine Frage wäre jetzt also, welche Möglichkeiten es ganz allgemein gibt die Sendegeschwindigkeit zu erhöhen.
Dabei wäre ich schon dankbar wenn einfach mal ein paar relevante Begriffe in den Raum geworfen würden damit ich überhaupt erstmal weiß wonach ich suchen muss.

----
Ich habe vergessen zu erwähnen, dass diese Zahlen zustande kommen wenn die Clienten zwischen denen die Nachrichten hin und hergeschickt werden auf dem Selben Rechner laufen.

cu

EDIT:
Sollte vielleicht noch erwähnen dass ich Windowssockets verwende.

Edit: Es kann auch Einiges von der Programmierung von deinem Server und Client abhängen, vielleicht ist da noch Optimierungsbedarf?

Ich bin im Netzwerkbereich noch ein ziemlicher Anfänger und bin gerade mal soweit ein kleinen Chat gemacht zu haben, da ist es nicht so wichig möglichst Viele Nachrichten möglichst schnell zu übertragen.
Doch arbeite ich ja darauf hin meine kleinen Spielchen Netzwerkfähig zu machen und ich habe bis jetzt noch keinerlei Vorstellungen wie wichtig in diesem Bereich eine hohe Nachrichtenanzahl ist, weil bevor ich mir darüber den Kopf zerbreche wie ich meine Spielchen ein wenig umfunktioniere wollte ich erst allgemein mit der Netzwerkprogrammierung Erfahrungen sammeln.
Falls 1700 Nachrichten a 4 Byte für Zeitkritische Spiele (also viel Aktion, viele Kollisionsmöglichkeiten usw) weit mehr Nachrichten sind als ich brauche (so wie ich es dachte bevor ich die Raknetzahlen sah) soll es fürs Erste gut sein, aber dennoch wäre es dann noch interessant zu erfahren wie man Nachrichtenzahlen erhöht (vielleicht durch eine manuelle Limitierung auf X Byte pro nachricht (???), falls das so einfach geht).

EDIT:
Dein Post hatte ich beim Verfassen diese Nachricht noch nicht gesehen Badestrand.

Aber was meine Programmierung an Server und Client angeht.
Speziell für diesen Test habe ich alles ziemlich roh gestaltet, damit so wenig wie möglich vorhanden ist das die Verbindung behindern könnte.
Ich habe direkt im Quellcode die nötigen Strukturen schon mit den richtigen Portangaben und der IPadresse gefüllt. Keine Klasse oder sonstige ordnenden Strukturen.
Hab alles so roh wie es mir möglich war erstellt.
Das ist also alles in der Standardeinstellung mit möglichst wenig Zeug dazwischen.

also bei rund 1700 messages hast du aber immer noch nur rund 0,87 Mbit,..

d.h. wenn du beim aufstocken von 4byte bis rund 40 bytes eine veränderung der geschwindigkeit merkst, liegt das definitiv an deinem source/rechner,..(denk ich mal)

seid gegrüßt

EDIT:
Bevor man jetzt auf die Idee kommt ich würde bei der Nachrichtenberechnung irgendein Blödsinn machen, soll gesagt sein, die Methode ist alles andere als geheimnisvoll.
ich habe eine globale intvariable (testzaehler) die zu Beginn auf 0 gesetzt wird.
Sobald der Nachrichtenaustausch beginnt (beginnt per Knopfdruck) wird testzaehler kontinuirlich um 1 erhöt wenn der Server recv() aufruft und eine Nachricht bekommt.
Drückt man beim Server auf eine Schaltfläche wird testzaehler wieder auf 0 gesetzt und ein Timer gestartet der der auf eine Sekunde gestellt ist.
Ist eine Sekunde vergangen wird der Wert von testzaehler ausgegeben.

DWORD wEvent, wError;

SOCKET client;
SOCKADDR_IN addr;
WSADATA wsa;

[...]

	WSAStartup(MAKEWORD(2,0), &wsa);
	client = socket( AF_INET, SOCK_STREAM, 0);
	addr.sin_family = AF_INET;
	addr.sin_port = htons(12345);
	addr.sin_addr.S_un.S_addr = inet_addr("xxx.xx.x.xx");
	connect(client, (SOCKADDR*)&addr, sizeof(SOCKADDR_IN));

	WSAAsyncSelect(client, modeless,
				WM_EIGENESETZWERK, FD_READ | FD_WRITE | FD_CONNECT | FD_ACCEPT | FD_CLOSE);

Das passiert in der Main beim Klienten, alles so roh wie möglich und alles direkt eingegeben.

Analog für den Server:

DWORD wEvent, wError;

SOCKET server;
SOCKET client;
SOCKADDR_IN addr;
WSADATA wsa;

[...]
	WSAStartup(MAKEWORD(2,0), &wsa);
	server = socket( AF_INET, SOCK_STREAM, 0);
	addr.sin_family = AF_INET;
	addr.sin_port = htons(12345);
	addr.sin_addr.S_un.S_addr = ADDR_ANY;
	bind(server, (SOCKADDR*)&addr, sizeof(SOCKADDR_IN));

	listen(server, 8);

	WSAAsyncSelect(server, modeless,
				WM_EIGENESETZWERK, FD_READ | FD_WRITE | FD_CONNECT | FD_ACCEPT | FD_CLOSE);

Und hier wird das ganze Nachrichtengedöns abgehandelt (für den clienten)

case WM_EIGENESETZWERK:
		wEvent = WSAGETSELECTEVENT(lParam); // d.h. LOWORD
		wError = WSAGETSELECTERROR(lParam); // d.h. HIWORD
		// Behandlung zweier für WSAAsyncSelect spezifizierte Ereignisse
		switch(wEvent)
		{
		case FD_ACCEPT:   
			break;
		case FD_READ:
			recv(client, buf, 4, 0);
// recv(client, buf, 40, 0);
			send(client, "aaa", 4, 0); // <- 4 byte-Version
                           //send(client, "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa", 40, 0); // <- 40 byteversion
			break;

analog für den Server:

case WM_EIGENESETZWERK:
		wEvent = WSAGETSELECTEVENT(lParam); // d.h. LOWORD
		wError = WSAGETSELECTERROR(lParam); // d.h. HIWORD
		// Behandlung zweier für WSAAsyncSelect spezifizierte Ereignisse
		switch(wEvent)
		{
		case FD_ACCEPT:   
			client = accept(server, 0, 0);
			break;
		case FD_READ:
			recv(client, buf, 4, 0);
// recv(client, buf, 40, 0);
			testzaehler++;

			send(client, "aaa", 4, 0);
//send(client, "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa", 40, 0); // <- 40 byteversion
			break;

// EDIT:
Wenn ich auf dem Button beim Server drücke

case IDOK:
				os << testzaehler;
				SetWindowText(GetDlgItem(hDlg, IDC_STATIC2), os.str().c_str());
				os.str("");				
				SetTimer(hDlg, 1, 1000, 0);
				testzaehler = 0;
				break;

addr.sin_addr.S_un.S_addr = inet_addr("xxx.xx.x.xx");

ich hoffe das hast du nur ersetzt damit man deine i-net addy nich kennt,..

2.)
wieso hast du in einem Clienten einen fd_Set??

3.)
passe doch deinen buffer an,...

4.)
deinen accept befehlt verstehe ich nicht,.. der ist doch

int accept(int s, struct sockaddr *addr, socklen_t *addrlen);

5.)
ok, die warteschlange ist 8, acceptierst aber immer nur eine verbindung,
aber schliesst diese wieder nicht,...

ich glaube der fd_set ist ohne schliessen der verbindung, bzw. nur eine verbindung zur gleichen zeit sinnlos, d.h. du hast log. immer mehr offene und AFAIR immer mehr nachrichten die gelesen werden wollen,..wenn du sie nicht schliesst,..

entweder nimmst du n array of sockets, bei accept natürlich neue zuweisen, invalide sofort diskonnecten,...

dann solltest du noch recv() auf null prüfen, denn dann wurde die gegenseite geschlossen bzw. -1 gabs n error,..

grüße

Hab nicht viel Ahnung von Internet/Netzwerken, mir wurde einfach mal gesagt ich soll das machen, weil man meine Internetip einfach rausfinden könne wenn man sich auskennt und wenn man dann in verbindung meine genaue lokale IP kenne gäbe es keine hürde mehr.
So wurde es mir zu mindest gesagt.
Und da es niemanden so schadet mache ich das einfach mal.

Ich habe den geposteten Quellcode hier durchgeschaut, kann jedoch keine fd_set-Struktur entdecken oO.
Sollte dort jedoch eine sein und ich sehe die nur nicht, hat sie keine Funktion, denn ich verwende sie nicht und ist in dem Fall nur ein Überbleibsel früherer Tests(sofern da überhaupt noch eine ist, wo soll die denn sein?
Falls du diese FD-Nachrichten meinst, die hängen mit WSAASyncSelect zusammen und nicht mit einer fd_set-Struktur).

Hab ich gemacht, das stocken war dann weg und es wurden nicht soviele Nachrichten versendet, aber genau so viele wie bei 4 byte.

Nun ja, der parameter s ist ja das Socket welches die Verbindungsanfrage enthält, die restlichen sind ja optional und da ich im Rahmen dieses Tests weder die IP des Clienten noch die größse der addr_in Struktur benötige sind die restlichen Parameter halt 0 und füllen nichts aus.
Zurückgegeben wird ja das (der?) Socket welcher die Anfrage gestellt hat (der client) und wird im Socket gespeichert der den Namen "client" trägt.

Wie gesagt, dieses Programm ist ein reines Testprogramm zum zählen der Nachrichten.
diese 8 ist eine willkürliche Zahl gewesen die keinen besonderen Sinn hat, dort hätte genauso gut 1 oder auch 30 stehen können.
Ich brauche für diesen Test halt nur eine Verbindung, halt die des einen Clienten mit dem der Server die Nachrichten austauscht damit dieses Hin und her gezählt werden kann.
(und die fd_set-Struktur kann ich immer noch nicht finden).

Und schließen brauche ich mein Socket auch nicht, das ist ein Testprogramm welches neben dem gepostetn gerade noch so viel Code enthält, sodass ich das alles komplilieren und ausführen kann. Wenn das Socket also geschlossen wird, dann deshalb, weil ich das Testprogramm selbst schließe.
recv brauche ich auch nicht auf 0 zu prüfen.
die FD_READ nachricht erhalte ich ausschließlich dann, wenn dort was zu lesen ist. Das hängt mit WSAAsyncSelect zusammen(so viel ich weiß ist das zu mindest so).

Und ist dir bewußt das WSAAsyncSelect den Socket in den Non-Blocking Modus setzt?

das sorgt dafür dass das prog nicht wartet bis eine verbindung eingeht,..
nimm mal die WSAAsync struktur erstmal gänzlich raus, die benötigst Du nur falls du im nonblockingmodus arbeiten,.. beziehungsweise ein ganzes SET von eingehenden verbindungen quasi in einem stück abarbeiten willst,...

lies dir dazu mal das tut von c-workers http://www.c-workers.ch durch um einen einfachen client und server im konsolenmodus zu erstellen,..

(copy n paste ? )

sei gegerüßt

Das ich durch WSAAsyncSelect im Nonblockingmodus arbeite wusste ich nicht, doch ist das ein großes Problem wenn sich sowieso Windows darum kümmert?

Also als Konsolenprogramm hatte ich ja schon einen Chat programmiert der der auch mehrere Clienten bedient (hier hatte ich wirklich fd_set verwendet).
Der Grund warum ich jetzt hier WSAASyncSelect verwende ist der,
dass ich in einem Windowsprogramm (mit DirectX und einem Winapi-Fenster) gerne eine Asynchrone Netzwerkverbindung hätte ohne selbst mit Threads oder sowas arbeiten zu müssen.
Ich lese immer wieder wie kompliziert das sei, dort vernünftig zu arbeiten.
Und weil cih sowieso für Windows programmiere (halt DirectX) hatte ich mir gedacht diese WindowsHilfsfunktionen tun nicht weh.

Aber jetzt mal ganz unabhängig welche Methode ich jetzt verwende, gibt es eien Möglichkeit die Mindestpaketgröße zu ändern?
Hier wurde ja mal gesagt die Mindestgröße sei 64 byte.
Was könnte ich also tun um die Mindestgröße z.B. auf 4 byte zu setzen?

Ab jetzt werde ich dann auch in solchen Tests den Rückgabewert prüfen, dachte eigentliclh immer, dass ein "Nichtganzfüllen" bei 4 byte eigentlich eine große Ausnahme wäre.

cu

Wenn bei dir Client und Server auf demselben Rechner laufen, könnte ich mir aber auch vorstellen, dass relativ viel vom System abhängt, UDP/TCP dürfte hier keine allzu große Rolle spielen, da eigentlich keine Pakete verloren gehen können.

bei udp können schon pakete verloren gehen. ausserdem ist udp weit weniger komplex als tcp und die tatsache, dass man bei udp auf die prüfsummen verzichten kann, macht es nochmals 'ne ganze ecke schneller. aber grundsätzlich gilt für beide, dass man die pakete schön voll machen muss (bei tcp hat man leider wenig einfluss darauf), um guten durchsatz zu erreichen.

Das ich durch WSAAsyncSelect im Nonblockingmodus arbeite wusste ich nicht, doch ist das ein großes Problem wenn sich sowieso Windows darum kümmert?

Das heisst lediglich das Funktionen die unter normalen Umständen warten würden bis nen Timeout eintritt oder bis Daten da sind, SOCKET_ERROR mit WSAEWOULDBLOCK via WSAGetLastError() zurückliefern täten.
Aber da du Rückgabewerte von recv() etc. sowieso auswerten solltest weniger tragisch

Kahino schrieb:

Aber jetzt mal ganz unabhängig welche Methode ich jetzt verwende, gibt es eien Möglichkeit die Mindestpaketgröße zu ändern?

Nicht wirklich...
Man kann zwar mit setsockopt() an den Socket-Buffern rumschrauben, allerdings entsprechen die Socket-Buffergrößen nicht zwangsweise den TCP-Buffern.
Wobei ich meine da könnte man über irgendwelche Registry-Einträge was machen...

Bei UDP können auch lokal Pakete verloren gehen, je nachdem wie schnell man die raus haut und beschäftigt das System so ist...