|
|
|
|
|
|
| Author |
Message |
andrew.sch
*nix forums beginner
Joined: 16 Jul 2006
Posts: 2
|
 Posted: Sun Jul 16, 2006 2:00 pm Post subject:
Why would accept() return a strange socket descriptor value?
|
|
|
Dear ALL,
I'm trying to trace network activity of a proxy server using truss
utility. The final goal is to be able to track times of the requests
being processed, but for the moment I'm simply trying to learn what's
going on inside (the program is a binary with no sources available).
$ truss -t accept,listen,read,write,connect,send,recv,bind <program
with arguments>
listen(256, 1024, 1) = 0
accept(256, 0xF680F9A8, 0xF680FAA8, 1) = 4
recv(257, " G E T / H T T P / 1".., 4096, 0) = 398
send(257, " H T T P / 1 . 1 4 0 3".., 2151, 0) = 2151
This is the interesting part of the log. Everything is quite trivial
with exception of returned value of accept(). According to
documentation accept() should return the socket descriptor which should
be used in calls to recv() and send(). But the value returned by
accept() differs from the value used in recv()/send(), and I cannot
understand it.
I'm sure the call sequence is correct, because I initiate the HTTP
request manually from a browser.
Could somebody explain why accept() returns 4 while recv()/send() work
with 257?
Thank you in advance,
Andrew
P.S. Forgot to mention that I work on SunOS 5.8 |
|
| Back to top |
|
 |
barts@smaalders.net
*nix forums addict
Joined: 03 Feb 2005
Posts: 74
|
| Posted: Sun Jul 16, 2006 3:25 pm Post subject:
Re: Why would accept() return a strange socket descriptor value?
|
|
|
andrew.sch wrote:
| Quote: | Dear ALL,
I'm trying to trace network activity of a proxy server using truss
utility. The final goal is to be able to track times of the requests
being processed, but for the moment I'm simply trying to learn what's
going on inside (the program is a binary with no sources available).
$ truss -t accept,listen,read,write,connect,send,recv,bind <program
with arguments
listen(256, 1024, 1) = 0
accept(256, 0xF680F9A8, 0xF680FAA8, 1) = 4
recv(257, " G E T / H T T P / 1".., 4096, 0) = 398
send(257, " H T T P / 1 . 1 4 0 3".., 2151, 0) = 2151
This is the interesting part of the log. Everything is quite trivial
with exception of returned value of accept(). According to
documentation accept() should return the socket descriptor which should
be used in calls to recv() and send(). But the value returned by
accept() differs from the value used in recv()/send(), and I cannot
understand it.
I'm sure the call sequence is correct, because I initiate the HTTP
request manually from a browser.
Could somebody explain why accept() returns 4 while recv()/send() work
with 257?
|
Your program is clearly not doing what you think it is. Accept returns
the
fd for the connected socket for the new connection. Recv and send are
using a different socket (eg connection) than that returned by accept.
Don't forget, many browser use multiple connections, so that may cause
some
confusion....
- Bart |
|
| Back to top |
|
|
tmp123
*nix forums Guru Wannabe
Joined: 23 Feb 2005
Posts: 169
|
| Posted: Sun Jul 16, 2006 5:30 pm Post subject:
Re: Why would accept() return a strange socket descriptor value?
|
|
|
andrew.sch wrote:
| Quote: |
$ truss -t accept,listen,read,write,connect,send,recv,bind <program
with arguments
listen(256, 1024, 1) = 0
accept(256, 0xF680F9A8, 0xF680FAA8, 1) = 4
recv(257, " G E T / H T T P / 1".., 4096, 0) = 398
send(257, " H T T P / 1 . 1 4 0 3".., 2151, 0) = 2151
Could somebody explain why accept() returns 4 while recv()/send() work
with 257?
|
Because your program also has "pipe" channels or similars?
try -d -l -t ...,open,close |
|
| Back to top |
|
|
Casper H.S. Dik
*nix forums Guru
Joined: 20 Feb 2005
Posts: 1634
|
| Posted: Sun Jul 16, 2006 5:46 pm Post subject:
Re: Why would accept() return a strange socket descriptor value?
|
|
|
"andrew.sch" <aschetinin@gmail.com> writes:
| Quote: | $ truss -t accept,listen,read,write,connect,send,recv,bind <program
with arguments
listen(256, 1024, 1) = 0
accept(256, 0xF680F9A8, 0xF680FAA8, 1) = 4
recv(257, " G E T / H T T P / 1".., 4096, 0) = 398
send(257, " H T T P / 1 . 1 4 0 3".., 2151, 0) = 2151
This is the interesting part of the log. Everything is quite trivial
with exception of returned value of accept(). According to
documentation accept() should return the socket descriptor which should
be used in calls to recv() and send(). But the value returned by
accept() differs from the value used in recv()/send(), and I cannot
understand it.
I'm sure the call sequence is correct, because I initiate the HTTP
request manually from a browser.
Could somebody explain why accept() returns 4 while recv()/send() work
with 257?
|
Becaus eyou didn't trace all system calls and you rpobably missed a
call like:
fcntl(4, F_DUPFD, 256) = 257
Casper |
|
| Back to top |
|
|
andrew.sch
*nix forums beginner
Joined: 16 Jul 2006
Posts: 2
|
| Posted: Mon Jul 17, 2006 7:39 am Post subject:
Re: Why would accept() return a strange socket descriptor value?
|
|
|
| Quote: |
Becaus eyou didn't trace all system calls and you rpobably missed a
call like:
fcntl(4, F_DUPFD, 256) = 257
|
Thank you for solving the mistery! 
This is exactly as you said. I was suspecting that the descriptor is
being duplicated, but did not know which system function would do it.
listen(256, 1024, 1) = 0
accept(256, 0xF680F9A8, 0xF680FAA8, 1) = 4
fcntl(4, F_DUPFD, 0x00000100) = 257
fcntl(257, F_SETFD, 0x00000001) = 0
fcntl(257, F_GETFL, 0x00000000) = 2
fcntl(257, F_SETFL, 0x00000082) = 0
recv(257, " G E T / H T T P / 1".., 4096, 0) = 237
fcntl(4, F_DUPFD, 0x00000100) = 258
fcntl(258, F_SETFD, 0x00000001) = 0
send(257, " H T T P / 1 . 1 4 0 3".., 2151, 0) = 2151
fcntl(257, F_GETFL, 0x00000000) = 130
fcntl(257, F_SETFL, 0x00000002) = 0
Now I'm wondering why would the duplicate be needed? Probably for
setting flags for the descriptor, mostly for FD_CLOEXEC. And may be
also for O_NONBLOCK which is set differently for recv() and send().
Sincerely,
Andrew |
|
| Back to top |
|
|
James Carlson
*nix forums Guru
Joined: 23 Feb 2005
Posts: 310
|
| Posted: Mon Jul 17, 2006 2:01 pm Post subject:
Re: Why would accept() return a strange socket descriptor value?
|
|
|
"andrew.sch" <aschetinin@gmail.com> writes:
| Quote: | Now I'm wondering why would the duplicate be needed? Probably for
setting flags for the descriptor, mostly for FD_CLOEXEC. And may be
also for O_NONBLOCK which is set differently for recv() and send().
|
Using the duplicate gets the descriptor number out of the precious
0-255 range, which is all that an old-style FILE * can use (due to
legacy binary accesses to FILE._file).
--
James Carlson, KISS Network <james.d.carlson@sun.com>
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 |
|
| Back to top |
|
|
Casper H.S. Dik
*nix forums Guru
Joined: 20 Feb 2005
Posts: 1634
|
| Posted: Tue Jul 18, 2006 8:56 pm Post subject:
Re: Why would accept() return a strange socket descriptor value?
|
|
|
"andrew.sch" <aschetinin@gmail.com> writes:
| Quote: | Now I'm wondering why would the duplicate be needed? Probably for
setting flags for the descriptor, mostly for FD_CLOEXEC. And may be
also for O_NONBLOCK which is set differently for recv() and send().
|
Because the application does not want to encroach upon the low fds which
are the only ones stdio can use.
(A problem which can now be avoided in Solaris NEvada)
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth. |
|
| Back to top |
|
|
Google
|
|
| Back to top |
|
|
|
|
The time now is Thu Jan 08, 2009 7:34 am | All times are GMT
|
|
Car Finance | Search Rapidshare | Debt Consolidation | Credit Card Consolidation | internet marketing secrets
|
|
Copyright © 2004-2005 DeniX Solutions SRL
|
|
|
|
Other DeniX Solutions sites:
Unix/Linux blog |
electronics forum |
medicine forum |
science forum |
|
|
Privacy Policy
|
Powered by phpBB © 2001, 2005 phpBB Group
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
Forum index
»
*nix
»
Solaris
