TCP /IP
-
hmm... sondern?also ich hatte am anfang mal gedacht ich hab ne thread der die verbindungen aufbaut, also auf verbindungen wartet, einen der für das senden zuständig ist und einer der daten empfängt.
die drei müssen sich dann in gewissen zeitabständen mal dran lassen..
bekommt man das hin? oder wie sollte man da ran gehen?
-
individuum schrieb:
also ich hatte am anfang mal gedacht ich hab ne thread der die verbindungen aufbaut, also auf verbindungen wartet, einen der für das senden zuständig ist und einer der daten empfängt.
kannste so machen. ist das einfachste. dann brauchste auch keine sockets in den non-blocking modus umkonfigurieren...
-
ok, dann werd ich das mal so versuchen.. danke für die hilfe
ist es dann eigentlich möglich einen meldung an alle zu versenden?
-
individuum schrieb:
ist es dann eigentlich möglich einen meldung an alle zu versenden?
klar, wenn 'accept' rauskommt, haste ja einen 'kommunikationssocket'. den musste sowieso irgendwo speichern, also packste den in ein array oder eine liste und wenn du was an alle senden willst, dann gehste die in 'ner schleife durch und machst sowas wie:
for (int s=0; s<number_of_conneted_socket; s++) send (connected_sockets[s], .....);
-
bei der frage hat ich eigentlich an gleichzeitig gedacht, hab mich da wohl nicht klar genug ausgedrückt

die frage ist ob das überhaupt muss,
ich sende höchstens 126 KB bei 100Mbit/s100Mbit/s -> 12,5MByte/s
also brauch ich für 126KB 0,01s also 10 millisekunden.
also theoretisch natürlich kommt da noch tcp header und son kram zu..ist das richtig gerechnet?
kann ich eigentlich beliebig große Datein versenden oder muss ich die noch aufsplitten?mfg
-
individuum schrieb:
100Mbit/s -> 12,5MByte/s
nee, aber nicht wirklich

diese 100 Mbits/s sind wirklich der absolute maximalwert, mit dem die bits durch's medium schwirren können (bei ethernet 100BaseT z.b. sind's 125µS zwischen zwei clock pulsen). die nutzdatenrate liegt bei ethernet durch protokolloverhead, kollisionen, latenzzeiten der hardware, etc. deutlich niedriger. beispiel: wenn du von einem 10Mbit/s ethernet auf ein 100Mbit/s ethernet wechselst, haste keine 10fach höhere nutzdatenrate (wie man annehmen sollte), sondern nur etwa eine 2 bis 2.5 fache!
dazu kommen noch die schlimmsten bremsen: software - (anwendung, tcp/ip, treiber etc.) und schon ist die nutzdatenrate im keller...individuum schrieb:
kann ich eigentlich beliebig große Datein versenden oder muss ich die noch aufsplitten?
du brauchst nichts selber zu zerstückeln. allerdings musste aufpassen, wenn du der 'send'-funktion z.b. 1000 bytes gibt, und die meldet als rückgabewert: 700, dann musst du die fehlenden 300 bytes beim nächsten aufruf von 'send' nochmal schicken...
-
net schrieb:
individuum schrieb:
ist es dann eigentlich möglich einen meldung an alle zu versenden?
klar, wenn 'accept' rauskommt, haste ja einen 'kommunikationssocket'. den musste sowieso irgendwo speichern, also packste den in ein array oder eine liste und wenn du was an alle senden willst, dann gehste die in 'ner schleife durch und machst sowas wie:
for (int s=0; s<number_of_conneted_socket; s++) send (connected_sockets[s], .....);is doch scheisse. wenn eine verbindung lahm ist müssen alle darunter leiden.
-
-------- schrieb:
is doch scheisse. wenn eine verbindung lahm ist müssen alle darunter leiden.
ja, wenn ein socket blockt ist das doof

naja, wenn er pro socket einen extra thread aufmacht, dann könnte man z.b. einen event auslösen o.ä. damit der betreffende thread das selber macht...
-
wann blockt ein socket?
was da vll erschwerend hinzukommt..
die clienten sind per w lan angebunden und es kann durchaus sein das da mal einer aus der reichweite der repeater latscht!wie lange versucht er denn das zu senden?
oder bricht er das dann ziemlich zügig ab?
-
individuum schrieb:
wann blockt ein socket?
unterschiedlich. von der sendeseite betrachtet: wenn die anwendung den socket mit daten vollgepumpt hat, er aber das zeug noch nicht loswerden konnte (schlechte verbindung o.ä.)...
individuum schrieb:
was da vll erschwerend hinzukommt..
die clienten sind per w lan angebunden und es kann durchaus sein das da mal einer aus der reichweite der repeater latscht!
wie lange versucht er denn das zu senden?
oder bricht er das dann ziemlich zügig ab?naja, kommt drauf an. wenn einer beim wlan ausser reichweite gerät, dann bekommen das theoretisch alle mit (der client selber empfängt keine beacons mehr und der access point weiss auch irgendwie dass der client nicht mehr da ist). so'n wlan-treiber liefert diese information auch nach oben, aber ich weiss nicht was windoofs damit anstellt (wie netwerkkabel abgezogen?). kann sein dass offene tcp/ip-verbindungen noch 'ne weile bleiben (kann ja, sein, dass ich der client wieder einfindet oder per roaming an einem anderen AP hängt)...
-
Wenn die verbindung verloren geht, muss ich dann ne reconnect ausführen?
oder kann ich so tun als wäre nichts gewesen?
-
ich hät da noch ne frage..
Gibt es eine Funktion die überpüft ob daten zu verfügung stehen?
sowas wie dataavailable?
bei .net gibs das ja, gibs das auch bei den CSockets?
-
select()
-
net schrieb:
individuum schrieb:
100Mbit/s -> 12,5MByte/s
nee, aber nicht wirklich

diese 100 Mbits/s sind wirklich der absolute maximalwert, mit dem die bits durch's medium schwirren können (bei ethernet 100BaseT z.b. sind's 125µS zwischen zwei clock pulsen). die nutzdatenrate liegt bei ethernet durch protokolloverhead, kollisionen, latenzzeiten der hardware, etc. deutlich niedriger. beispiel: wenn du von einem 10Mbit/s ethernet auf ein 100Mbit/s ethernet wechselst, haste keine 10fach höhere nutzdatenrate (wie man annehmen sollte), sondern nur etwa eine 2 bis 2.5 fache!
dazu kommen noch die schlimmsten bremsen: software - (anwendung, tcp/ip, treiber etc.) und schon ist die nutzdatenrate im keller...net, das stimmt so net

Ich hab selbst schon über ein 100mbit Netz >7mb/sec drübergedrückt - das ist kein Problem. Solange man nicht viel Kollisionen hat -- bloss die bremsen ein 10mbit Netz genauso.
Sogar aus meinem 1000mbit Netz bekomm ich mehr als 25mb/sec raus (nämlich ca. 40mb/sec), und das ohne Server Netzwerkkarten (mit Server Netzwerkkarten kommt man schon auf > 60mb/sec).
-
hustbaer schrieb:
net, das stimmt so net

Ich hab selbst schon über ein 100mbit Netz >7mb/sec drübergedrückt...tjä, ausnahmen bestätigen die regel. was ich da geschrieben hab' stammt von 'nem vergleich windoofs <--> selbstgebastelter hardware, 100mbits ethernet, tcp/ip loopback in einem kleinem netzwerk (1 switch, etwa 5 teilnehmer dran), paketgrössen zwischen etwa 600 und 1460 bytes.
windows(xp) <--> windows(xp) war sogar ein tickchen langsamer (etwa 2MB/s).btw: was sind server netzwerkkarten?
-
nett schrieb:
select()
da find ich nicht recht was zu..
also ich möchte eine automatische reconncet funktion erstellen:
wie kann man das unterbinden das er bei Socket.listen() eweig wartet?
-
net schrieb:
btw: was sind server netzwerkkarten?
Das sind welche wo "Server" draufsteht

Die sind dann teurer als "normale", aber eben schneller. Im Prinzip einfach bessere Karten, und meist mit PCI-X oder neuerdings PCIe Anbindung.Die haben dann auch bessere Treiber, erledigen diverse Aufgaben auf der Karte (teile des TCP/IP Stacks), und können über Busmaster selbst diverse "Auftragslisten" aus dem RAM holen und abarbeiten -- so dass die CPU nichtmehr für jedes einzelne blöde Packet nen PCI Zugriff machen muss.
Im Endeffekt haste mit einer guten Server Netzwerkkarte kaum CPU Auslastung während das Teil jenseits der 60MB/sec über 1000Base-T raushaut.
----
Klar kann man auch einfach "gute Netzwerkkarte" dazu sagen, bloss Intel z.B. verwendet den Begriff selbst ("Intel PRO/1000 MT Server Adapter"), und kaum ein Heimanwender kauft sich so eine teure Karte, von daher finde ich es nicht verkehrt einfach "Server Netzwerkkarte" zu sagen -- so wie man ja auch "Server Platte" sagt etc.
-
hustbaer schrieb:
Die haben dann auch bessere Treiber, erledigen diverse Aufgaben auf der Karte (teile des TCP/IP Stacks), und können über Busmaster selbst diverse "Auftragslisten" aus dem RAM holen und abarbeiten -- so dass die CPU nichtmehr für jedes einzelne blöde Packet nen PCI Zugriff machen muss.
wow, find ich interessant. wo krieg ich infos darüber?
-
Hier steht ganz wenig zu "was", aber nicht zu "wie":
http://www.intel.com/network/connectivity/resources/doc_library/data_sheets/pro1000mt_sa_dual.pdfAnsonsten... keine Ahnung

Ich hab das mal auf der NTDEV Mailing Liste von OSR (www.osronline.com) aufgeschnappt (is ne offene Sache, kannst dich ja mal eintragen wenn dich Treiber Entwicklung und so interessiert - gute Leute dort). Da hat auch einer vorgerechnet dass man ne gigabit Karte die in einem normalen PCI Slot steckt sowieso nichtmehr ausreizen kann wenn die CPU für jedes Paket ("Frame" oder wie das im Ethernet Fachjargon heisst) extra ran muss um die Karte anzusprechen. Leider kenn ich mich mit DMA bei PCI Karten und generell PCI Zugriffen nicht so aus -- ich vermute aber dass ein PCI Zugriff per CPU auf ein einzelnes Register wesentlich mehr als einen PCI Zyklus dauert.
Is auch irgendwie logisch dass bessere Netzwerkkarten sowas können sollten. Macht wenig Sinn z.B. für jedes empfangene Paket nen Interrupt zu generieren und die liebe CPU zu bitten ne neue Adresse im Speicher für das nächste Paket bereitzustellen bzw. die alten Daten aus dem DMA Bereich rauszukopieren. Ist doch viel besser wenn man der Karte sagt "da haste 10MB Speicher, geh spiel damit wie du meinst, und wenn du nen paar Pakete reinbekommen hast, oder eines und dann nen paar nanosekunden nixmehr, dann mach mir nen Interrupt". Salopp gesagt

-
hustbaer schrieb:
Ist doch viel besser wenn man der Karte sagt "da haste 10MB Speicher, geh spiel damit wie du meinst, und wenn du nen paar Pakete reinbekommen hast, oder eines und dann nen paar nanosekunden nixmehr, dann mach mir nen Interrupt"
klar, was anderes ist bei nic's >100mbits/s wohl auch nicht sinnvoll

wobei ich mal gehört habe, dass die ix86-kisten pci-dma nur sehr unzureichend unterstützen (busmaster kann keine virtuellen adressen benutzen, es können keine dma-aktionen zusammengefasst werden, keine scatter listen etc.). naja, aber als verkaufsargument ist ja sowas trotzdem gut.... :xmas2: