TCP stream socket lockup problem

TCP stream socket lockup problem

Post by Gib Bog » Wed, 23 Aug 1995 04:00:00



I have been running some tests with TCP stream sockets, and have run into
a random crash problem - a severe lockup that requires a hard reset.
I am using kernel version 1.1.47, running on a 486/33 and P90, with
NE2000 clone ethernet cards.

My test programs are a TCP server (started by tcpd) and a TCP client that
sends 10000 blocks, each block 1500 bytes.  The client uses writen()
(i.e. iterated write as in Stevens "UNIX Network Programming"), while the
server just reads with readn() (iterated read of 1500 bytes) and discards
the block.  Running these programs both on the 486 gives no problems.
When the client is on the P90, it runs fine most of the time, then locks
the machine at some point.  In my latest test I ran the client about 10
times in quick succession (in the foreground), left it for a few minutes,
ran it again and got a lockup.

There are many candidates for the source of this problem.  Perhaps the
most likely is that this is a bug in my kernel version that has been fixed
by 1.2.X.  I am hoping that someone will tell me that this is so.
I have to wonder whether my cheap Addtron ethernet cards could be to
blame, although I have seen no problems using nfs or ftp (transfer rates
up to 400 k/s).  Could it be related to the PCI bus in the P90?  

Any ideas out there?

- Gib

 
 
 

TCP stream socket lockup problem

Post by Rene Pijlma » Thu, 24 Aug 1995 04:00:00



>I have been running some tests with TCP stream sockets, and have run into
>a random crash problem - a severe lockup that requires a hard reset.
>I am using kernel version 1.1.47, running on a 486/33 and P90, with
>[...]
>Any ideas out there?

The 1.<odd>,x kernels are development versions, whereas the 1.<even>.x
kernels are 'production' quality. Since 1.3 is now in development, I don't
think that bug reports on 1.1 are useful anymore. To the very least you
should upgrade to 1.2.x.

Regards,
--
Rene Pijlman

%DCL-MEM-BAD, bad memory
VMS-F-PDGERS, pudding between the ears

 
 
 

1. SSL tunneling for TCP/IP stream sockets application

I have a client/server system which is using TCP/IP stream
sockets for its communication. The server is written in C
and is running on UNIX (several flavours).

There are a couple of client applications - one written
in C++ and another in Java that have to talk to this server.
The client apps. are not all running on UNIX, one is running
on NT.

I would like to use SSL encryption on for the communications
happening b/w the clients and the server. After having looked
at www.openssl.org, I have realized that using SSL libraries
to provide SSL encryption for the clients and the server is
not feasible since one of the clients is written in Java and
using JNI would make the client too complicated. Also, I would
like to separate the clients and servers from the details of
the actual SSL protocol and the key management issues.

I am looking for another type of solution where some kind of
SSL proxy server(s) can be used to provide an SSL tunnel b/w
the clients and the server for encrypted communications. This
way I wouldn't have to worry about the SSL library compatibility
for the clients, and the clients and server would not need to
know anything about the SSL protocol or any key management issues.

The clients and the server are typically communicating over
a public Internet TCP/IP connection, and are not on the same
machine.

Are are there any tools/packages that can provide an SSL
tunnel to be used by the clients and the server for their
communication ?

Thanks for any information.

--
Salman Ahmed
ssahmed AT interlog DOT com

2. SunFire-V210 and disk size...

3. tcp socket stream slow

4. Can one set up RAID with IDE drives?

5. SSL tunneling for TCP/IP stream socket applications

6. Delayed systerm logger at start ups

7. tcp/ip socket stream: slow to send

8. Which is more likely to be damaged - CPU or Motherboard ?

9. How to push STREAMS module into socket stream

10. SCO 3.2.4.2, TCP/IP 1.21 termial overrun and lockup problems, heeeelp

11. Problem whith TCP/IP streams

12. Problem with TCP/IP streams

13. Socket problem, streaming data