By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
448,760 Members | 2,113 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 448,760 IT Pros & Developers. It's quick & easy.

Binding problem - address already in use

P: n/a
I have server, daemon and client (daemon and client on the same machine).
When client starts it send query to the server, server send query
to the deamon (daemon check if the client exist), daemon send a response
to the server, server send a response to the client.

First I had following numbers of udp ports:
S_PORT 2613 /* Server Port number */
S1_PORT 2614 /* Server Port for Daemon response */
C_PORT 2620 /* Client Port number */
S_APP_PORT 2624 /* application info port */
D_PORT 2619 /* Daemon Port number */

Above configuration was good on various unix systems
(IRIX, HP-UX, SunOS, SuSE) except RedHat.
bind() function put in errno EADDRINUSE - Address already in use

Then I read in RedHat info:
"If you write a server that is not one of the standard ones defined in
the database, you must choose a port number for it. Use a number
greater than `IPPORT_USERRESERVED'; such numbers are reserved for
servers and won't ever be generated automatically by the system.
Avoiding conflicts with servers being run by other users is up to you."

So I changed the ports as follow (because IPPORT_USERRESERVED == 5000):
S_PORT 5006 /* Server Port number */
S1_PORT 5002 /* Server Port for Daemon response */
C_PORT 5003 /* Client Port number */
S_APP_PORT 5004 /* application info port */
D_PORT 5007 /* Daemon Port number */

It's working on RedHat9.0 but it's not working on RedHat7.3

I know that during binding the client socket I can give 0
instead a number of port (kernel will bind the number of client port
dynamically) but during binding server socket I must specify
number of server port (client must know where will send the data to)

Is there some function in unix which reserve port for my server?
Help me please, I'am beginner in unix network programming.

Regards,
Aleksander Wodynski
Nov 13 '05 #1
Share this Question
Share on Google+
2 Replies


P: n/a
Aleksander Wodynski <no************@o2.pl> scribbled the following:
I have server, daemon and client (daemon and client on the same machine).
When client starts it send query to the server, server send query
to the deamon (daemon check if the client exist), daemon send a response
to the server, server send a response to the client.


Hold it. ISO standard C, the topic of this newsgroup, defines no
networking facilities whatsoever. Please ask in a newsgroup dedicated to
your own implementation. Thanks.

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"I am looking for myself. Have you seen me somewhere?"
- Anon
Nov 13 '05 #2

P: n/a
On Wed, 01 Oct 2003 19:27:11 +0200, Aleksander Wodynski
<no************@o2.pl> wrote in comp.lang.c:
I have server, daemon and client (daemon and client on the same machine).
When client starts it send query to the server, server send query
to the deamon (daemon check if the client exist), daemon send a response
to the server, server send a response to the client.


[snip]

The C language has no built-in support for networking. It does not
support daemons, sockets, or bind(). All of these are platform
specific extensions, so this is not a language issue.

You need to ask in a group like news:comp.unix.programmer or one of
the news:comp.os.linux.development.* groups. The question is
off-topic here.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq
Nov 13 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.