home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!aspentec!tto
- From: tto@aspentec.com
- Newsgroups: comp.protocols.tcp-ip.ibmpc
- Subject: Problem with Pathwork sockets
- Message-ID: <1992Aug31.113142.860@aspentec.com>
- Date: 31 Aug 92 11:31:41 EST
- Distribution: world
- Organization: Aspen Technology, Inc. Cambridge, MA.
- Lines: 34
-
- I have read some news articles regarding problems with Pathwork TCP/IP's socket
- library. Here's my share of woes:
-
- Our company has an application that uses sockets to open a telnet connection
- to a host. This application runs well on several different sites but fails
- rather frequently on a particular client's. It seems that the host sometimes
- takes an unreasonable long time to respond to a simple command. I decided
- to log the characters that were actually sent and received. It turned out
- that in these occasions the command was not echoed for a long period of time.
- It looked as if the socket procedure send() were faking sending characters:
- it would return 0 but store up the characters in an internal buffer and send
- them at a later time. (Note that the delays were way beyond normal TCP
- timeout periods.)
-
- I am using...
- SOCKTSR.EXE "3Com SOCKETS (1.1)" (I have also tried 1.2)
- TCPTSR.EXE "3COm DOS Unloadable TCP/IP Protocol Driver 1.2"
- TCPDRV.DOS "3Com Resident TCP/IP Protocol Driver 1.2"
-
- Here is some related info:
-
- 3COM wrote the socket library; DEC only licensed the binary (and not the
- source). After a lot of phone calls and delays, I finally got someone in
- DEC who promised that he would try to get the info from 3COM to help solving
- my problem.
-
- Does anyone has any insight?
-
- Tak.
- -----------------------------------------------------------------------------
- Tak To (617) 497-9020 x377
- Aspen Technology, Inc Fax: (617) 497-7806
- 243 Vassar St, Cambridge, Ma 02139. tto@aspentec.com
- -----------------------------------------------------------------------------
-