Puncte:3

Doar un singur socket TCP (prin nc) poate trimite date la aceeași gazdă/port simultan

drapel in

Reproducere simplă - într-o fereastră urmăriți procesele în partea de sus, în cealaltă rulați: nc -lkp 10000 > /dev/null & ( head -50000000 /dev/urandom | nc -N 127.0.0.1 10000 ) & ( head -50000000 /dev/urandom | nc -N 127.0.0.0 1) 1

Observă că numai una cap și nc proces utilizează în mod activ CPU.

Atașați strace la cap care nu este activ - vezi că este blocat la o scriere, de exemplu:

strace: Proces 589084 atasat
scrie(1, „\264\347\270\26\27\24'BRb^\353\302\36@\216\17V\210*n\252`\353\330\351\276\2\250 \330\350\217"..., 4096^Cstrace: Procesul 589084 detașat
 <detașat...>

Configurați doi ascultători pe porturi diferite - de ex. 10000 și 10001 și ambele merg la viteză maximă.

Acesta este un exemplu simplu, dar îl pot reproduce cu alte intrări și ieșiri - de ex. zcatting fișiere mari și trimiterea lor către serviciile de producție prin rețea. Nu are legătură cu intrarea și nici cu priza de ascultare.

Așadar, de ce pot avea o singură conexiune tcp la orice gazdă/port care trimite în mod activ date?

Există o sursă de date independentă (simțiți-vă liber să experimentați dacă nu mă credeți) și un proces independent care își deschide propria conexiune tcp (netstat le va arăta pe amândouă deschise) - singurul lucru în comun este destinația (care nu trebuie neapărat să fie un nc ascultând mai departe uite - se întâmplă cu orice).

Având în vedere că destinația poate avea cu siguranță mai multe prize de intrare care primesc date simultan, iar sursa poate trimite cu siguranță date în mai multe prize de rețea simultan, mă chinui să-mi dau seama de unde vine disputa, determinând ca doar o conductă să fie activă la o singura data.

Ron Maupin avatar
drapel us
Un port poate fi revendicat doar printr-un singur proces. Trebuie să lăsați aplicația să folosească porturi efemere pentru sursă (portul `0`), unde porturile sursă sunt alese „aleatoriu” pentru fiecare proces. O conexiune TCP este identificată prin adresele sursă și destinație și porturile sursă și destinație. Dacă folosiți aceleași valori pentru toate cele patru, atunci este, prin definiție, aceeași conexiune, iar încercarea de a rula un nou proces pe aceeași conexiune va genera o eroare.
garethhumphriesgkc avatar
drapel in
Există diferite porturi sursă utilizate de fiecare conexiune. Așa funcționează nc în mod implicit, a doua instanță nu s-ar deschide dacă portul sursă era deja în uz și puteți vedea în ieșirea netstat că sunt diferite. Vă asigur că sunt două conexiuni TCP diferite - vă încurajez să încercați și să vedeți.
Puncte:8
drapel cl
A.B

Disclaimer: sunt multe nc variante. Presupunând din -k că este varianta OpenBSD. Fiecare nc varianta are propriile sale avantaje.

nc este instrumentul greșit pentru acest job: nc -lkp 10000 va gestiona o conexiune în același timp, deoarece nu se bifurcă și în ciuda utilizării sondaj(2) nu foloseste niciodata accept (2) pe o a 2-a conexiune de intrare până la finalizarea primei conexiuni: este o garanție că a 2-a conexiune va fi lăsată netratată. Dacă mai sunt câteva, vor începe să rămână înăuntru SYN-SENT stare deoarece nc -lkp 10000 folosește 1 ca asculta (2) restanță: aceasta nu este o alegere aleatorie. Acest lucru poate fi verificat folosind strace pe alergare nc -lkp 10000 proces.

The documentatie despre -k opțiunea spune același lucru:

-k

Când o conexiune este finalizată, ascultă încă unul. Necesită -l.
[...]

modul în care este scris nu sugerează că vor fi acceptate două conexiuni în același timp: doar una în spatele precedentului.


Înlocuiește ascultarea netcat cu socat (-d -d pentru informatii suplimentare):

socat -d -d tcp4-listen:10000,reuseaddr,fork /dev/null

The furculiţă opțiunea asigură o procesare paralelă ușoară: un proces per conexiune.

garethhumphriesgkc avatar
drapel in
Mulțumesc pentru sfat - socat se comportă așa cum era de așteptat. Acum trebuie să lucrez de ce nu face java - totuși, asta sună ca o postare stackoverflow.
A.B avatar
drapel cl
A.B
Încearcă mai mult. primele sunt „autoconectate” de către OS. În mod normal, asta depinde de restanța, dar ar putea mai fi câteva. Aici al 4-lea (adică al 3-lea neprocesat) primește primul SYN-SENT (cu `ss -tn dst == 127.0.0.1:10000`)
garethhumphriesgkc avatar
drapel in
Îmi pare rău A.B - Mi-am șters comentariul după ce am văzut că ați modificat răspunsul pentru a-l aborda, dar înainte de a vă vedea răspunsul. Pentru cei care vin mai târziu, am menționat doar că conexiunile ulterioare au fost complet stabilite, nu în SYN_SENT.
A.B avatar
drapel cl
A.B
Vorbesc despre conexiuni în așteptare: cele nc care așteaptă să fie procesate. Au cel puțin 4 clienți nc care rulează în același timp (înainte de primul dintre aceste 4 capete) pentru a vedea acest lucru. Comportamentul exact poate depinde de versiunea kernelului și de setările acesteia, doar încercați cu mai multe. Exemplul dvs. din OP rulează doar doi clienți, astfel încât acest comportament nu va fi văzut.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.