HP3000-L Archives

April 1997, Week 1

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
James Wowchuk <[log in to unmask]>
Reply To:
James Wowchuk <[log in to unmask]>
Date:
Mon, 7 Apr 1997 22:33:12 +1000
Content-Type:
text/plain
Parts/Attachments:
text/plain (54 lines)
At Wed, 2 Apr 1997 08:58:00 PST, Richard Trapp RAT <[log in to unmask]> wrote,
>Help,
>    We're having an interesting problem with our client server listener
>process on the 3k:
>
>After our listening daemon receives an accept() call for a new socket
>connection request from a 16-bit windows client on its well known
>listening port, if a new socket from a different client is requested on
>the listener port, when we try and do a recv() on the original request,
>the socket connection has been lost according to the errno we get back
>from recv().   The error we often see from recv() when it returns a -1 is
>"Connection has been reset by peer"; or,  when we get a zero receive
>length back from recv(), hp tells us that this means the connection has
>been lost.   We see differing results, which are likely determined by the
>timing of when the second request is made.
>To the best of our knowledge, this problem is only happening when the
>server is an hp3000 and the client is a 16-bit windows application.
>What we are trying to find out is if there is anything we should do
>differently to handle almost simultaneous connections.
> --------

1)  What we do need to know is what API are you using on the HP3000 end.  Is
it the NetIPC or BSD Sockets?

2) Are you doing anything special in the processing - that is are you using
no-wait I/O?  If not, how are you determining when to do a receive
connection and when to do receive?

When you create your server, you should be expecting at least two sockets:
one the call socket that you use to receive connections with, the other the
virtual circuit socket.  The second is returned from the first.  While more
connections can be received on the first, each virtual circuit returned
needs to be held independantly.

My first guess is that your second receive connection call is overwriting the
virtual circuit socket returned from the first receive connection call.  Can
you confirm this isn't the case?

I can't imagine why it should make a difference whether the client was
16-bit or 32-bit if the connections are being established from different
machines.  If you are using asynchronous I/O (event driven), then you should
check that you are trapping all events.

I hope this helps.


----
Jim Wowchuk
Vanguard Computer Services Internet:   [log in to unmask]
 _--_|\                    Compu$erve: <gone>
/      \                   Post:       PO Box 18, North Ryde, NSW 2113
\_.--._/ <---Sydney NSW    Phone:       +61 (2) 888-9688
      v      Australia     Fax:         +61 (2) 888-3056

ATOM RSS1 RSS2