heeeelp - socket problem 
Author Message
 heeeelp - socket problem

I've encountered a problem.....
I am using a socket connection for local/remote IPC
in what I think is fairly standard SOCK_STREAM mode but have run into a
brick wall. Initially I developed some code for rather specific data
transfers with handshakes for various 'internal' specifics - no problem.
However on increasing the size of some of the transfers the socket
completely blocks!!!!! The sending side is unaware and returns number of
bytes sent satisfactorily but the receiving side dies completely. The
behaviour does not seem to follow any specific pattern but for a
particular swequence of string transfers is totally reproducable in
failing at the same point.
Am I using sockets incorrectly ?
Is there some buffering aspect I am missing, a protocol problem or what?
With the shorter string transfers(<500chars) data zipped around happily
for days but with longer strings(~3000chars) it dies almost immediately?

 - desparate for any assistance please..

Nick Belshaw / Oxford Geochemistry



Tue, 25 Jan 2000 03:00:00 GMT  
 heeeelp - socket problem

Hi,

  Isn't the underlying implementation using "send/recv" instead of
  "read/write" for the sake portablility (to MS-Winsock)?  If so, is
  send/recv limited to the size of a non-fragmentable packet (hence smaller
  than typical MTU of 1500 for ethernet, less for others, but way less than
  ~3000?).

Quote:

> I've encountered a problem.....
> I am using a socket connection for local/remote IPC
> in what I think is fairly standard SOCK_STREAM mode but have run into a
> brick wall. Initially I developed some code for rather specific data
> transfers with handshakes for various 'internal' specifics - no problem.
> However on increasing the size of some of the transfers the socket
> completely blocks!!!!! The sending side is unaware and returns number of
> bytes sent satisfactorily but the receiving side dies completely. The
> behaviour does not seem to follow any specific pattern but for a
> particular swequence of string transfers is totally reproducable in
> failing at the same point.
> Am I using sockets incorrectly ?
> Is there some buffering aspect I am missing, a protocol problem or what?
> With the shorter string transfers(<500chars) data zipped around happily
> for days but with longer strings(~3000chars) it dies almost immediately?

>  - desparate for any assistance please..

> Nick Belshaw / Oxford Geochemistry

--
--
Cheers,
        --ldl
-----------------------------------------------------------------------------

HealthPartners, 8100 34th Avenue So, PO Box 1309, Minneapolis, MN  55440-1309
Shape your life not from your memories, but from your hopes.       (Borrowed)
Still programming for the day-job... haven't yet gotten that Microsoft PR job
-----------------------------------------------------------------------------
"But it sure is easier just to sit back and {*filter*} than to actually try to
 make yourself heard."  -- Jim Edwards-Hewitt
-----------------------------------------------------------------------------


Tue, 25 Jan 2000 03:00:00 GMT  
 heeeelp - socket problem

I don't think this is the problem. The UNIX man pages (I'm looking at NeXT
and Linux), say:

If the message is too long to pass atomically through the underlying
protocol, the error EMSGSIZE is returned and the message is not
transmitted.

If I get time, I'll consult SunOS 4.1.3.

Nick says that his sends are going satisfactorily, which makes sense since
he's using a SOCK_STREAM (TCP). If it had been a SOCK_DGRAM (UDP), this
would indeed be too large a message. Though I seldom do blocking sends in
practice with TCP sockets, I have seen quite large buffers sent in single
send calls when the socket is set to blocking. Perhaps there are different
semantics in Windows, but that would seem strange.

Tom



Quote:
> Hi,

>   Isn't the underlying implementation using "send/recv" instead of
>   "read/write" for the sake portablility (to MS-Winsock)?  If so, is
>   send/recv limited to the size of a non-fragmentable packet (hence
smaller
>   than typical MTU of 1500 for ethernet, less for others, but way less
than
>   ~3000?).


> > I've encountered a problem.....
> > I am using a socket connection for local/remote IPC
> > in what I think is fairly standard SOCK_STREAM mode but have run into a
> > brick wall.
> > Is there some buffering aspect I am missing, a protocol problem or
what?
> > With the shorter string transfers(<500chars) data zipped around happily
> > for days but with longer strings(~3000chars) it dies almost
immediately?

> >  - desparate for any assistance please..

> > Nick Belshaw / Oxford Geochemistry



Thu, 27 Jan 2000 03:00:00 GMT  
 heeeelp - socket problem

This sounds like a problem with the higher-level protocol to me. As an
example, if you talk to the tcp/echo server it will send back
everything you send it. If you don't read this data soon enough the
return connection will eventually block. I.e. with the echo server
there is some limit to the send size at which your connection will
deadlock, because both parties are waiting for their send buffers to
flush.

--
--
Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++

http://www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm



Thu, 27 Jan 2000 03:00:00 GMT  
 
 [ 4 post ] 

 Relevant Pages 

1. socket problems under windows: cannot load Socket.so under windows

2. Heeeelp :-)

3. Heeeelp :-)

4. heeeelp, how do I

5. heeeelp!!

6. Heeeelp before I shoot myself

7. bsr r1,r2 Heeeelp

8. HEEEELP ! Looking for a memory dumper

9. Heeeelp! Cobol, windows 95 and Novell

10. heeeelp!

11. Tk on solaris 2.4 (Heeeelp !)

12. SSL support for socket module for server sockets

 

 
Powered by phpBB® Forum Software