Hi
I am Using Allegro C.L.6.2 on red hat Linux 9
At one top level i executed the following lines of code
(let* ((con (acl-socket:make-socket :connect :passive :local-port 3456))
(buf(acl-socket:accept-connection con)))
(pprint (read-line buf))(close buf)(close con))
At another top level i connected to the above server (via client socket) and i
had written one line of out put to server socket.
At the first top level the line from the client is getting printed.
Again I repeated the above lines of code at the first top level and I got
the following exception
Error: "Local socket address already in use" (errno 98) occured while
creating a passive socket.
[condition type: socket-error]
Restart actions (select using :continue):
0: Return to Top Level (an "abort" restart).
1: Abort entirely from this process.
[1] cl-user(79):
I have to implement the above scenario in a real time environment.
Please give me solution to the above problem
Venkat wrote:
> Hi
>
> I am Using Allegro C.L.6.2 on red hat Linux 9
>
> At one top level i executed the following lines of code
>
> (let* ((con (acl-socket:make-socket :connect :passive :local-port 3456))
> (buf(acl-socket:accept-connection con)))
> (pprint (read-line buf))(close buf)(close con))
>
> At another top level i connected to the above server (via client socket) and i
> had written one line of out put to server socket.
>
> At the first top level the line from the client is getting printed.
>
>
> Again I repeated the above lines of code at the first top level and I got
> the following exception
>
>
> Error: "Local socket address already in use" (errno 98) occured while
> creating a passive socket.
> [condition type: socket-error]
>
> Restart actions (select using :continue):
> 0: Return to Top Level (an "abort" restart).
> 1: Abort entirely from this process.
> [1] cl-user(79):
>
>
>
> I have to implement the above scenario in a real time environment.
> Please give me solution to the above problem
Just a guess: did the top-level sender code also close the socket after
sending the one line of text?
kt
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton <·······@nyc.rr.com> wrote in message news:<·······················@twister.nyc.rr.com>...
> Venkat wrote:
>
> > Hi
> >
> > I am Using Allegro C.L.6.2 on red hat Linux 9
> >
> > At one top level i executed the following lines of code
> >
> > (let* ((con (acl-socket:make-socket :connect :passive :local-port 3456))
> > (buf(acl-socket:accept-connection con)))
> > (pprint (read-line buf))(close buf)(close con))
> >
> > At another top level i connected to the above server (via client socket) and i
> > had written one line of out put to server socket.
> >
> > At the first top level the line from the client is getting printed.
> >
> >
> > Again I repeated the above lines of code at the first top level and I got
> > the following exception
> >
> >
> > Error: "Local socket address already in use" (errno 98) occured while
> > creating a passive socket.
> > [condition type: socket-error]
> >
> > Restart actions (select using :continue):
> > 0: Return to Top Level (an "abort" restart).
> > 1: Abort entirely from this process.
> > [1] cl-user(79):
> >
> >
> >
> > I have to implement the above scenario in a real time environment.
> > Please give me solution to the above problem
>
> Just a guess: did the top-level sender code also close the socket after
> sending the one line of text?
>
> kt
No sender code does not close the socket after sending the line of text?
My requirement is sender may or may not close the socket?
Venkat wrote:
> Kenny Tilton <·······@nyc.rr.com> wrote in message news:<·······················@twister.nyc.rr.com>...
>
>>Venkat wrote:
>>
>>
>>>Hi
>>>
>>> I am Using Allegro C.L.6.2 on red hat Linux 9
>>>
>>> At one top level i executed the following lines of code
>>>
>>> (let* ((con (acl-socket:make-socket :connect :passive :local-port 3456))
>>> (buf(acl-socket:accept-connection con)))
>>> (pprint (read-line buf))(close buf)(close con))
>>>
>>> At another top level i connected to the above server (via client socket) and i
>>> had written one line of out put to server socket.
>>>
>>> At the first top level the line from the client is getting printed.
>>>
>>>
>>> Again I repeated the above lines of code at the first top level and I got
>>> the following exception
>>>
>>>
>>> Error: "Local socket address already in use" (errno 98) occured while
>>> creating a passive socket.
>>> [condition type: socket-error]
>>>
>>> Restart actions (select using :continue):
>>> 0: Return to Top Level (an "abort" restart).
>>> 1: Abort entirely from this process.
>>> [1] cl-user(79):
>>>
>>>
>>>
>>> I have to implement the above scenario in a real time environment.
>>> Please give me solution to the above problem
>>
>>Just a guess: did the top-level sender code also close the socket after
>>sending the one line of text?
>>
>>kt
>
>
>
> No sender code does not close the socket after sending the line of text?
> My requirement is sender may or may not close the socket?
I have only done client-side stuff and others here are much stronger on
sockets, but I am about to code up my first server, and I plan to just
leave the socket open on the server side and redirect any senders to a
different port specific to each. I am just mimicking what I saw with one
particular server (the RoboCup Simulator). It only accepted "init"
messages on the documented port, then responded with an init
confirmation and a new port for that sender to continue on.
Note that this is more about sockets and client-server, so if you are
puzzled by the above you might want to research those topics (ie, at
this stage it does not seem that Lisp is the problem). Not chasing you
away, just trying to help.
kt
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
>>>>> "KT" == Kenny Tilton <·······@nyc.rr.com> writes:
[...]
KT> I have only done client-side stuff and others here are much
KT> stronger on sockets, but I am about to code up my first
KT> server, and I plan to just leave the socket open on the server
KT> side and redirect any senders to a different port specific to
KT> each.
Why? It is perfectly fine to have many connections to the same port.
If nothing else, you make your server box more complicated to firewall
by doing what you plan to.
KT> I am just mimicking what I saw with one particular
KT> server (the RoboCup Simulator). It only accepted "init"
KT> messages on the documented port, then responded with an init
KT> confirmation and a new port for that sender to continue on. [...]
You need to look into why they did it that way, maybe they had a good
reason (not being able to work the sockets API is not a good reason, IMHO).
I like Stevens' books on TCP/IP, but the on-line FAQ's are also OK.
cheers,
BM
Bulent Murtezaoglu wrote:
>>>>>>"KT" == Kenny Tilton <·······@nyc.rr.com> writes:
>
> [...]
> KT> I have only done client-side stuff and others here are much
> KT> stronger on sockets, but I am about to code up my first
> KT> server, and I plan to just leave the socket open on the server
> KT> side and redirect any senders to a different port specific to
> KT> each.
>
> Why?
Who knows? To determine client identity?
> I like Stevens' books on TCP/IP, but the on-line FAQ's are also OK.
Thx for the leads.
kt
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton <·······@nyc.rr.com> writes:
> Bulent Murtezaoglu wrote:
> >>>>>>"KT" == Kenny Tilton <·······@nyc.rr.com> writes:
> > [...]
> > KT> I have only done client-side stuff and others here are much
> > KT> stronger on sockets, but I am about to code up my first
> > KT> server, and I plan to just leave the socket open on the server
> > KT> side and redirect any senders to a different port specific to
> > KT> each. Why?
>
> Who knows? To determine client identity?
it has to do with forking servers, each time the server handled a request
it forked( made a copy of itself) to do the work. Here is a man page for
fork:
http://www.freebsd.org/cgi/man.cgi?query=fork+&apropos=0&sektion=0&manpath=FreeBSD+4.9-stable&format=html
now one of the things a process cannot share is a socket. So what happens
is in the ack packet ( tcp 3-way handshake syn -> ack -> syn-ack) the server
sends back the port of the forked new process in the ip header so the client
knows where to go. Some servers prefork( apache) and the master server will
direct clients to one of its fellows. If you are going to use threads the
only reason I can think of to open new sockets is that with each new socket
you get a new buffer to store incoming packets in and if a lot of clients
are hitting one port you may get swamped and loose traffic. But most/all
os's allow you to tune the size of the buffer, but this is a global in
most/all cases(every socket gets X times normal buffer not just yours).
If you want to get a Stevens book get:
Unix Network Programming, Vol. 1: The Sockets Networking API, Third Edition
Its a programmers eye view of tcp/ip, it examples are in C though and it
just came out.
I like TCP/IP Illistrated also but it is getting a bit dated
marc
ps this all assumes unix or unix like OS, sockets came from bsd unix.
marc
>>>>> "MS" == Marc Spitzer <········@optonline.net> writes:
[...]
MS> now one of the things a process cannot share is a socket.
Um. The scheme is usually that you accept, accept creates a NEW
socket, then you fork, and the kid uses the new socket and the parent
closes it. The listening socket continues to be used by the parent
and can be closed in the kid.
MS> So
MS> what happens is in the ack packet ( tcp 3-way handshake syn ->
MS> ack -> syn-ack) the server sends back the port of the forked
MS> new process in the ip header so the client knows where to go.
No, nothing like that in the IP header piggybacked to the ack from the
server. The ports remain the same. I think what you are missing is
that accept returns a new socket ('connected socket'). Things remain
unique even though the server port/IP stays the same because the client
IP/port is different for the next connection.
MS> ... If you are going to use
MS> threads the only reason I can think of to open new sockets is
MS> that with each new socket you get a new buffer to store
MS> incoming packets in and if a lot of clients are hitting one
MS> port you may get swamped and loose traffic.
You always get a new socket when you accept, with its own buffer.
If you hadn't written this, I wouldn't have realized what was throwing
you off.
[...]
MS> If you want to get a Stevens book get: Unix Network
MS> Programming, Vol. 1: The Sockets Networking API, Third Edition
MS> Its a programmers eye view of tcp/ip, it examples are in C
MS> though and it just came out.
Hmm, today must be the day I disagree with you on almost everything.
Stevens passed away a few years ago. But maybe somebody did a second
edition? I don't have my copy handy but I think I got it in 98 or 99.
Definitely before NASDAQ went boom. In any event, I do agree that
that's a good book to get.
MS> I like TCP/IP Illistrated also but it is getting a bit dated
MS> marc
MS> ps this all assumes unix or unix like OS, sockets came from
MS> bsd unix.
Yeah, the concepts/syscalls are pretty much the same in Windows
though. For Lisp use, only the basics of tcp and how sockets work is
needed, commercial implementations prolly give you good interfaces (eg
you don't monkey with filling out C structs, and things like SIGPIPE
are lispified).
cheers,
BM
Bulent Murtezaoglu <··@acm.org> writes:
> >>>>> "MS" == Marc Spitzer <········@optonline.net> writes:
> [...]
> MS> now one of the things a process cannot share is a socket.
>
> Um. The scheme is usually that you accept, accept creates a NEW
> socket, then you fork, and the kid uses the new socket and the parent
> closes it. The listening socket continues to be used by the parent
> and can be closed in the kid.
>
> MS> So
> MS> what happens is in the ack packet ( tcp 3-way handshake syn ->
> MS> ack -> syn-ack) the server sends back the port of the forked
> MS> new process in the ip header so the client knows where to go.
>
> No, nothing like that in the IP header piggybacked to the ack from the
> server. The ports remain the same. I think what you are missing is
> that accept returns a new socket ('connected socket'). Things remain
> unique even though the server port/IP stays the same because the client
> IP/port is different for the next connection.
You are correct, I was thinking of binding to a socket already in use.
>
> MS> ... If you are going to use
> MS> threads the only reason I can think of to open new sockets is
> MS> that with each new socket you get a new buffer to store
> MS> incoming packets in and if a lot of clients are hitting one
> MS> port you may get swamped and loose traffic.
>
> You always get a new socket when you accept, with its own buffer.
> If you hadn't written this, I wouldn't have realized what was throwing
> you off.
I thought the buffer was tied to the port, in kernel space. Just checked
it out and you were right again(freebsd man socket page):
[ENOBUFS] Insufficient buffer space is available. The socket
cannot be created until sufficient resources are
freed.
>
> [...]
> MS> If you want to get a Stevens book get: Unix Network
> MS> Programming, Vol. 1: The Sockets Networking API, Third Edition
> MS> Its a programmers eye view of tcp/ip, it examples are in C
> MS> though and it just came out.
>
> Hmm, today must be the day I disagree with you on almost everything.
> Stevens passed away a few years ago. But maybe somebody did a second
> edition? I don't have my copy handy but I think I got it in 98 or 99.
> Definitely before NASDAQ went boom. In any event, I do agree that
> that's a good book to get.
>
> MS> I like TCP/IP Illistrated also but it is getting a bit dated
>
> MS> marc
>
> MS> ps this all assumes unix or unix like OS, sockets came from
> MS> bsd unix.
>
> Yeah, the concepts/syscalls are pretty much the same in Windows
> though. For Lisp use, only the basics of tcp and how sockets work is
> needed, commercial implementations prolly give you good interfaces (eg
> you don't monkey with filling out C structs, and things like SIGPIPE
> are lispified).
>
> cheers,
>
> BM
marc
Kenny Tilton <·······@nyc.rr.com> writes:
> Bulent Murtezaoglu wrote:
> >>>>>>"KT" == Kenny Tilton <·······@nyc.rr.com> writes:
> > [...]
> > KT> I have only done client-side stuff and others here are much
> > KT> stronger on sockets, but I am about to code up my first
> > KT> server, and I plan to just leave the socket open on the server
> > KT> side and redirect any senders to a different port specific to
> > KT> each. Why?
>
> Who knows? To determine client identity?
That may be an issue with UDP communication, for TCP, it shouldn't
(really) be an issue. All packets are identified by a tuple of:
<src ip, src port, dst ip, dst port> and two sending programs on the
same source should get different sending ports.
//Ingvar
--
My posts are fair game for anybody who wants to distribute the countless
pearls of wisdom sprinkled in them, as long as I'm attributed.
-- Martin Wisse, in a.f.p
>>>>> "V" == Venkat <············@yahoo.com> writes:
[...]
V> Error: "Local socket address already in use" (errno 98)
V> occured while creating a passive socket. [condition type:
V> socket-error] [...]
Do a google search for SO_REUSEADDR, or better yet brosw through Stevens'
TCP books for setting up (binding) listening sockets for servers. The FAQ
entry (from google) is:
http://www.manualy.sk/sock-faq/unix-socket-faq-4.html#ss4.5
This is not really a lisp question, but once the TCP sockets part is clear
you will need to look at Franz's documentation for setting the correct
option. Like so:
http://www.franz.com/support/documentation/6.2/doc/pages/operators/socket/make-socket.htm
cheers,
BM