---

Hvad er egentligt forskellen på når en daemon lytter til en port (f.eks.
10000) eller når der benyttes en socket, f.eks. /tmp/mysql.sock

Begge er vel "døre" til at kommunikere imellem programmer/net, men hvad er
forskellen?

En "fil socket" ligger jo et eller anden sted på disken. Hvad er denne fil
egentligt for noget? Er det blot en pointer til en plads i RAM, eller hvad
står der egentligt i den?

Hvordan med en daemon der lytter på en port. Laves der så også en fysisk fil
på disken/ram eller er det blot et spørgsmål om at der lyttes "over
netværket"?

Nogen der kan hjælpe lidt med at rede trådene ud?

--
Mvh
Michael

---

Hej Michael

Jeg ved ikke rigtig om det er det her du søger, men jeg prøver alligevel.

Når du har en daemon der kører og lytter på en port, har programmet (din
daemon) åbnet en socket og bedt om en bestemt port på computeren. Det er
således at man bruger port-nummeret til at mappe de enkelte
applikationer med.
Det der sker når din browser åbner en socket er at den requester en
tilfældig port på din computer, og får denne tildelt. Herefter sender
den en besked/pakke til en webserver og requester data på et bestemt IP
og portnummer. Dette portnummer varierer hele tiden og vil ligge i
området 1024-65536. Når browseren (eller et andet klient-program) har
modtaget de data den har bedt om lukker den porten igen - dvs. den
optager altså kun porten i et ganske kort stykke tid.

Så begge ting er såmænd sockets, men der er bare forskel i hvor lang tid
du har din socket.

Hvis du vil have lidt mere tjek på sockets vil det måske være en god ide
at kigge på lidt socket-programmering i Java. Det giver et pænt overblik
over hvad det egentlig er der sker, og hvordan de mest basale ting
virker. Kontakt mig på mail, hvis du vil have et lille eksempel på en
mini-webserver!

Hvad angår det med filer - så har jeg ikke en "hatfis" forstand på
hvordan *NIX lige håndterer den slags, så det må andre nok hellere forklare.


Mvh / Preben Holm


Michael wrote:
> Hvad er egentligt forskellen på når en daemon lytter til en port (f.eks.
> 10000) eller når der benyttes en socket, f.eks. /tmp/mysql.sock
>
> Begge er vel "døre" til at kommunikere imellem programmer/net, men hvad er
> forskellen?
>
> En "fil socket" ligger jo et eller anden sted på disken. Hvad er denne fil
> egentligt for noget? Er det blot en pointer til en plads i RAM, eller hvad
> står der egentligt i den?
>
> Hvordan med en daemon der lytter på en port. Laves der så også en fysisk fil
> på disken/ram eller er det blot et spørgsmål om at der lyttes "over
> netværket"?
>
> Nogen der kan hjælpe lidt med at rede trådene ud?
>
> --
> Mvh
> Michael

---

Preben wrote:

> Hvis du vil have lidt mere tjek på sockets vil det måske være en god
> ide at kigge på lidt socket-programmering i Java.

Java er et fantastisk daarligt sted at starte, hvis man vil vide noget
om, hvordan tingene reelt fungerer og haenger sammen. Du skal taenke
paa, at Java er platformsuafhaengigt, saa mange detaljer om
implementation af forskellige ting er ofte abstraheret vaek for at opnaa
platformsuafhaengigheden. At det saa ikke er gjort ordentligt hele vejen
igennem er en anden snak -- jeg undrer mig stadig over, at man ved
filnavne/-stier selv skal haandtere forskellen mellem Windows (\) og
unixer (/).

Naar det saa er sagt, saa minder Javas socket API vist en hel del om
BSD's socket API, der vist er defactostandarden.

Mvh. Michael.
--
Rumour is information distilled so finely that it can filter through
anything.
-- (Terry Pratchett, Feet of Clay)

---

>> Hvis du vil have lidt mere tjek på sockets vil det måske være en god
>> ide at kigge på lidt socket-programmering i Java.
>
>
> Java er et fantastisk daarligt sted at starte, hvis man vil vide noget
> om, hvordan tingene reelt fungerer og haenger sammen. Du skal taenke
> paa, at Java er platformsuafhaengigt, saa mange detaljer om
> implementation af forskellige ting er ofte abstraheret vaek for at opnaa
> platformsuafhaengigheden. At det saa ikke er gjort ordentligt hele vejen
> igennem er en anden snak -- jeg undrer mig stadig over, at man ved
> filnavne/-stier selv skal haandtere forskellen mellem Windows (\) og
> unixer (/).
>
> Naar det saa er sagt, saa minder Javas socket API vist en hel del om
> BSD's socket API, der vist er defactostandarden.

Tja, det kan da godt ske at Java for dit synspunkt måske er et dårligt
sted at starte, men desværre er det nu engang sådan at flere forskellige
bøger faktisk bruger java som eksempel, når man starter med at lære om
sockets og generel TCP/IP.
Og det er nok netop fordi det er så generelt som du beskriver. Det
forklarer rimelig godt hvad der egentlig sker og hvilke sockets der
faktisk anvendes og hvordan de anvendes på hhv. client og server.

Implementationsmæssigt som du selv siger kan det være væsentligt
anderledes, men det giver jo stadig en fornuftig "forklaring".
Well, jeg må sige at jeg ikke har lavet socket-programmering med c, men
kun med Java (desværre ikke haft så meget tid), og med c er der jo klart
den ulempe, at det er forskelligt, hvordan det virker fra platform til
platform. Operativsystemernes API er jo desværre ikke generaliserede!!!


Mvh / Preben Holm

---

Preben wrote:
> Implementationsmæssigt som du selv siger kan det være væsentligt
> anderledes, men det giver jo stadig en fornuftig "forklaring".
> Well, jeg må sige at jeg ikke har lavet socket-programmering med c, men
> kun med Java (desværre ikke haft så meget tid), og med c er der jo klart
> den ulempe, at det er forskelligt, hvordan det virker fra platform til
> platform. Operativsystemernes API er jo desværre ikke generaliserede!!!

Altsaa, jeg kender ingen unix, der ikke bruger BSD socket API (socket(),
bind(), listen(), connect() -- glemte jeg noget?).

Desuden, hvordan skal man laere noget om, hvordan tingene _reelt
virker_, hvis man kan faar en abstraktionsflade at se? Hvis jeg har fire
haandtag at dreje i, og disse haandtag drejer i nogle andre haandtag,
der styrer en maskine, saa ved jeg intet om, hvordan maskinen laengere
inde virker.

Abstraktionslaget er maaske meget smart, naar man skal anvende maskinen,
men det er udelukkende en forhindring, i det oejeblik hvor du kun vil
vide, hvordan tingene virker inde bagved.

Mvh. Michael.
--
Rumour is information distilled so finely that it can filter through
anything.
-- (Terry Pratchett, Feet of Clay)

---

Michael Knudsen <ether@cs.auc.dk> writes:

> Altsaa, jeg kender ingen unix, der ikke bruger BSD socket API

System V-streams?

> (socket(), bind(), listen(), connect() -- glemte jeg noget?).

Du mangler i hvert fald accept.

> Desuden, hvordan skal man laere noget om, hvordan tingene _reelt
> virker_, hvis man kan faar en abstraktionsflade at se? Hvis jeg har

Det skal lige bemærkes at socket-laget i aller højeste grad er en
abstraktion der skjuler en masse detaljer.

Men i øvrigt vil jeg give dig ret i at systemkald-laget mellem kernen
og userspace er det bedste sted at starte hvis man vil vide hvordan
ting virker. Så kan man altid bevæge sig ned og op derfra.

--
Peter Makholm | Yes, you can fight it, but in the end the ultimate
peter@makholm.net | goal of life is to have fun
http://hacking.dk | -- Linus Torvalds

---

"Michael" <ugyldig@email.dk> writes:

> Hvad er egentligt forskellen på når en daemon lytter til en port (f.eks.
> 10000) eller når der benyttes en socket, f.eks. /tmp/mysql.sock
>
> Begge er vel "døre" til at kommunikere imellem programmer/net, men hvad er
> forskellen?

Det er stort set det samme. Set fra programmernes side er der ikke den
store forskel når forbindelsen først er åbnet. Den eneste forskel er
navngivning og hvordan man styre rettigheder.

En fil-socket kan kun tilgås fra den lokale maskine og overholder
normal fil-rettighedssemantik. Om du kan læse og skrive fra en
fil-socket er altså præcis det samme som om du ville kunne læse og
skrive fra en tilsvarende fil.

En net-socket er åben mod netværket og kan tilgås fra andre
maskiner. Der er i selve net-socketen ingen rettighedsstyring., det
skal enten styres i programmet der læser fra socketen eller i et
firewall-lag.

> En "fil socket" ligger jo et eller anden sted på disken. Hvad er denne fil
> egentligt for noget? Er det blot en pointer til en plads i RAM, eller hvad
> står der egentligt i den?

Det er en fil i katalogstruklturen, men når man prøver at åbne den,
læse fra den eller skrive til den kalder man nogle andre funktioner
nede i kernen end for normale filer.

> Hvordan med en daemon der lytter på en port. Laves der så også en fysisk fil
> på disken/ram eller er det blot et spørgsmål om at der lyttes "over
> netværket"?

Der lyttes bare over netværket.

--
Peter Makholm | We constantly have to keep in mind why natural
peter@makholm.net | languages are good at what they're good at. And to
http://hacking.dk | never forget that Perl is a human language first,
| and a computer language second

---

Michael wrote:
> Nogen der kan hjælpe lidt med at rede trådene ud?

Foelgende guide omkring netvaerksprogrammering kan maaske hjaelpe dig
til at faa en bedre forstaaelse af maskineriet:

   http://www.ecst.csuchico.edu/~beej/guide/net/html/

Den drejer sig udelukkende omkring netvaerkssockets, men Peter har
egentlig paa udmaerket vis forklaret forskellen.

Det vigtige at forstaa er nok, at der er flere typer af sockets, men
grundlaeggende fungerer de ens.

Mvh. Michael.
--
Rumour is information distilled so finely that it can filter through
anything.
-- (Terry Pratchett, Feet of Clay)