Hozzászólások
-
Bejegyzés
-
ELaci wrote:Jé, gabaman!
Félévenként szokott felbukkani! 🙂ELaci wrote:Javaslom hogy szidjuk közösen Bábel elvtársat! Szemét egy alak volt na… 🙂Akkor fél év múlva újra megnézem mi változott…
„De az én programomban nincs is ->connect()”
Hmm, az ‘IO::Socket::INET()’ hivja meg, csak nem látszik.
„Tudnám máshogy is fogadni a kapcsolatot, hogy már a kiépülés után tudjak róla?”
Nem lehet, még C-ben sem, legalábbis hogy gondolod. A kapcsolat kétirányban kiépül, mielőtt az accept() visszaadná a vezérlést, a programodban csak az adatkommunikációt tudod befolyásolni, a kézfogást nem (ez látszik a netstat-ban).„Én -p kapcsolóval futtatom, de a kérdéses kapcsolatoknál nincs PID, csak egy – jel. Ebből én arra gondolok, hogy az én programom még egyáltalán nem indulhatott el.”
Egy szőke nő lehet úgy terhes, hogy a gyereknek nincs apja? 🙂 Ha nincs PID, akkor a progid már kilépett. Mivel forkolod, külön probléma lehet. Kommentezd ki, úgy sorban fogja a progid kezelni a kéréseket, de kiszűrsz egy hibalehetőséget. Lehet hogy minden jó, csak a forkolt rész lép ki túl hamar. Különben ha debugolsz, azonosítani kell megyik folyamatról van szó.
„Az én lezárásaim pedig azt hiszem, ebből a szempontból nem fontosak, hiszen el sem indul a programom.”
Ha így lenne, akkor hibaüzenetet kapnál. Ha a fork() nem megy, akkor neked kellene hibaüzit kreálnod.
„A TIME_WAIT állapotú kapcsolatokkal rendben vagyok. A kérdéses kapcsolataim ESTABLISHED állapotúak.”
A probléma az, hogy PID nélkül nem lenne szabad ESTABLISHED állapotnak lennie.
„De az én programomban nincs is ->connect()”
Hmm, az ‘IO::Socket::INET()’ hivja meg, csak nem látszik.
„Tudnám máshogy is fogadni a kapcsolatot, hogy már a kiépülés után tudjak róla?”
Nem lehet, még C-ben sem, legalábbis hogy gondolod. A kapcsolat kétirányban kiépül, mielőtt az accept() visszaadná a vezérlést, a programodban csak az adatkommunikációt tudod befolyásolni, a kézfogást nem (ez látszik a netstat-ban).„Én -p kapcsolóval futtatom, de a kérdéses kapcsolatoknál nincs PID, csak egy – jel. Ebből én arra gondolok, hogy az én programom még egyáltalán nem indulhatott el.”
Egy szőke nő lehet úgy terhes, hogy a gyereknek nincs apja? 🙂 Ha nincs PID, akkor a progid már kilépett. Mivel forkolod, külön probléma lehet. Kommentezd ki, úgy sorban fogja a progid kezelni a kéréseket, de kiszűrsz egy hibalehetőséget. Lehet hogy minden jó, csak a forkolt rész lép ki túl hamar. Különben ha debugolsz, azonosítani kell megyik folyamatról van szó.
„Az én lezárásaim pedig azt hiszem, ebből a szempontból nem fontosak, hiszen el sem indul a programom.”
Ha így lenne, akkor hibaüzenetet kapnál. Ha a fork() nem megy, akkor neked kellene hibaüzit kreálnod.
„A TIME_WAIT állapotú kapcsolatokkal rendben vagyok. A kérdéses kapcsolataim ESTABLISHED állapotúak.”
A probléma az, hogy PID nélkül nem lenne szabad ESTABLISHED állapotnak lennie.
Hello mindenkinek!
Na igen, így jár az, aki csomagok helyett forrásból telepít. A gtk+ 1.2.10 kpompatibilis a 1.2.2-vel, mivel a gtk+ 1.2 második és tizedik javításáról van szó. Ráadásul a régi gtk az iso8859-xx -et támogatja a Suse 10.2 meg UTF-8 alapú.
http://www.rpmfind.net/linux/rpm2html/search.php?query=gtk&submit=Search+…
A java esetén tényleg a fontok a probléma.
Hello mindenkinek!
Na igen, így jár az, aki csomagok helyett forrásból telepít. A gtk+ 1.2.10 kpompatibilis a 1.2.2-vel, mivel a gtk+ 1.2 második és tizedik javításáról van szó. Ráadásul a régi gtk az iso8859-xx -et támogatja a Suse 10.2 meg UTF-8 alapú.
http://www.rpmfind.net/linux/rpm2html/search.php?query=gtk&submit=Search+…
A java esetén tényleg a fontok a probléma.
Pár link:
http://www.open-xchange.com/
http://www.mozilla.org/projects/calendar/
http://wiki.mozilla.org/Calendar:FAQ
http://www.groupdav.org/
http://www.linux.com/articles/52035
http://ietf.osafoundation.org/caldav/
http://ietf.osafoundation.org/caldav/homepage/projects.html„Nem szívesen helyeznék üzembe egy Exchange szervert, ha van Linuxos megoldás is.”
Ne vedd személyeskedésnek, konkrétan nem neked szól, hanem általánosítok. Nagyon káros ez a hozzáállás, mivel ebből a mondatból süt, hogy a megfogalmazónak fogalma sincs a szabványok és ajánlások mibenlétéről. Csakhogy nem egyedi eset, hanem – itt Magyarországon – általánosan elterjedt szemlélet. Nem a konkrét szoftver a fontos (itt: Exchange), hanem a technológia (naptár munkacsoportos környezetben). Ezért nem is „Linuxos megoldás”-t kellene keresni először, hanem szabványokat, ajánlásokat. Itt van néhány:
iCalendar: RFC2445
Calendar Attributes for LDAP: RFC2739
Calendar Access Protocol (CAP): RFC4324
Calendaring Extensions to WebDAV (CalDAV): RFC4791Tehát aki _szabadon_ akar gondolkodni, az utánanéz a fenti ajánlásoknak (a lista nem teljes), és amelyik a célnak megfelelő, ahhoz néz szoftvert. Bár a legtöbb kliens szinte az összes ajánlást támogatja, így a kiszolgáló a kérdéses.
A fentieket ne vedd zokon, nekem az problémás, hogy nagyon nagy tömeget ráneveltek arra, hogy egy szolgáltatáshoz csak egy cég egy termékét kell/lehet használni. Gondolkodni meg nem kell, mert a sajtóanyag/iskola/oktatás/köztudat már tartalmaz minden lényeges információt.
Pár link:
http://www.open-xchange.com/
http://www.mozilla.org/projects/calendar/
http://wiki.mozilla.org/Calendar:FAQ
http://www.groupdav.org/
http://www.linux.com/articles/52035
http://ietf.osafoundation.org/caldav/
http://ietf.osafoundation.org/caldav/homepage/projects.html„Nem szívesen helyeznék üzembe egy Exchange szervert, ha van Linuxos megoldás is.”
Ne vedd személyeskedésnek, konkrétan nem neked szól, hanem általánosítok. Nagyon káros ez a hozzáállás, mivel ebből a mondatból süt, hogy a megfogalmazónak fogalma sincs a szabványok és ajánlások mibenlétéről. Csakhogy nem egyedi eset, hanem – itt Magyarországon – általánosan elterjedt szemlélet. Nem a konkrét szoftver a fontos (itt: Exchange), hanem a technológia (naptár munkacsoportos környezetben). Ezért nem is „Linuxos megoldás”-t kellene keresni először, hanem szabványokat, ajánlásokat. Itt van néhány:
iCalendar: RFC2445
Calendar Attributes for LDAP: RFC2739
Calendar Access Protocol (CAP): RFC4324
Calendaring Extensions to WebDAV (CalDAV): RFC4791Tehát aki _szabadon_ akar gondolkodni, az utánanéz a fenti ajánlásoknak (a lista nem teljes), és amelyik a célnak megfelelő, ahhoz néz szoftvert. Bár a legtöbb kliens szinte az összes ajánlást támogatja, így a kiszolgáló a kérdéses.
A fentieket ne vedd zokon, nekem az problémás, hogy nagyon nagy tömeget ráneveltek arra, hogy egy szolgáltatáshoz csak egy cég egy termékét kell/lehet használni. Gondolkodni meg nem kell, mert a sajtóanyag/iskola/oktatás/köztudat már tartalmaz minden lényeges információt.
linuxforum wrote:És meglepő módon ezek a kapcsolatok megmaradnak, bár a kliens eszközök lekapcsolódnak.Biztos, hogy a kliensek rendesen lezárják a kapcsolatot?
linuxforum wrote:Hogyn épülhet ki a kapcsolat, ha az én programom meg sem kapja a kapcsolatot?De megkapja, csak nem az accept(), hanem a connect() hozza létre a kapcsolatot.
3.3. Why does connect() succeed even before my server did an
accept()?From Andrew Gierth (andrew@erlenstar.demon.co.uk):
Once you have done a listen() call on your socket, the kernel is
primed to accept connections on it. The usual UNIX implementation of
this works by immediately completing the SYN handshake for any
incoming valid SYN segments (connection attempts), creating the socket
for the new connection, and keeping this new socket on an internal
queue ready for the accept() call. So the socket is fully open before
the accept is done.http://www.faqs.org/faqs/unix-faq/socket/
linuxforum wrote:Lehetséges egyáltalán hozzáférnem az ilyen kapcsolatokhoz?
Vagy ezek elvesztek a semmibe?Nem lehet hozzáférni az eldobott kapcsolatokhoz, a kernel fogja majd egy idő után halottnak nyilvánítani.
4.2. Why don’t my sockets close?
When you issue the close() system call, you are closing your interface
to the socket, not the socket itself. It is up to the kernel to close
the socket. Sometimes, for really technical reasons, the socket is
kept alive for a few minutes after you close it. It is normal, for
example for the socket to go into a TIME_WAIT state, on the server
side, for a few minutes. People have reported ranges from 20 seconds
to 4 minutes to me. The official standard says that it should be 4
minutes. On my Linux system it is about 2 minutes. This is explained
in great detail in „2.7 Please explain the TIME_WAIT state.”.Tehát ha a ‘létrejött’ (ESTABLISHED) jelzés van a szerver kilépése után is, akkor nincs jól lezárva a socket. Biztos, hogy minden kilépési pontnál lezárod a kapcsolatot (a hibáknál is)?A kliensek esetében a kliens gépen kell megnézni a port állapotát a kliens kilépését követően. A netstat használatakor használd a -p kapcsolót is, úgy biztosan tudni fogod, hogy kilépett-e valamelyik alkalmazás.
Ha többre vagy kíváncsi, használd a wireshark progit.
linuxforum wrote:És meglepő módon ezek a kapcsolatok megmaradnak, bár a kliens eszközök lekapcsolódnak.Biztos, hogy a kliensek rendesen lezárják a kapcsolatot?
linuxforum wrote:Hogyn épülhet ki a kapcsolat, ha az én programom meg sem kapja a kapcsolatot?De megkapja, csak nem az accept(), hanem a connect() hozza létre a kapcsolatot.
3.3. Why does connect() succeed even before my server did an
accept()?From Andrew Gierth (andrew@erlenstar.demon.co.uk):
Once you have done a listen() call on your socket, the kernel is
primed to accept connections on it. The usual UNIX implementation of
this works by immediately completing the SYN handshake for any
incoming valid SYN segments (connection attempts), creating the socket
for the new connection, and keeping this new socket on an internal
queue ready for the accept() call. So the socket is fully open before
the accept is done.http://www.faqs.org/faqs/unix-faq/socket/
linuxforum wrote:Lehetséges egyáltalán hozzáférnem az ilyen kapcsolatokhoz?
Vagy ezek elvesztek a semmibe?Nem lehet hozzáférni az eldobott kapcsolatokhoz, a kernel fogja majd egy idő után halottnak nyilvánítani.
4.2. Why don’t my sockets close?
When you issue the close() system call, you are closing your interface
to the socket, not the socket itself. It is up to the kernel to close
the socket. Sometimes, for really technical reasons, the socket is
kept alive for a few minutes after you close it. It is normal, for
example for the socket to go into a TIME_WAIT state, on the server
side, for a few minutes. People have reported ranges from 20 seconds
to 4 minutes to me. The official standard says that it should be 4
minutes. On my Linux system it is about 2 minutes. This is explained
in great detail in „2.7 Please explain the TIME_WAIT state.”.Tehát ha a ‘létrejött’ (ESTABLISHED) jelzés van a szerver kilépése után is, akkor nincs jól lezárva a socket. Biztos, hogy minden kilépési pontnál lezárod a kapcsolatot (a hibáknál is)?A kliensek esetében a kliens gépen kell megnézni a port állapotát a kliens kilépését követően. A netstat használatakor használd a -p kapcsolót is, úgy biztosan tudni fogod, hogy kilépett-e valamelyik alkalmazás.
Ha többre vagy kíváncsi, használd a wireshark progit.
legutóbbi hsz