TServerSocket/TClientSocket send buffer error 10053 and 10057

Thread View: borland.public.cppbuilder.internet.socket

5 messages

[T] Back to Threads [V] Tree View [G] Group Articles

5 total messages Started by newsgroups.borland.com Sun, 28 Oct 2007 16:54

#770

Author: newsgroups.borland.com
Date: Sun, 28 Oct 2007 16:54

87 lines
3578 bytes

Hi all,
I'm developing a simple audio streamer over LAN.
I have a TServerSocket in non-blocking listening on port 5678.
Then I have a TClientSocket that connect to the server.
When one or more connections are ready, the server receive 1000 byte chunk 
of wav data from the sound card and send to all the connected clients.
On the client side when a 1000 byte chunk is received it's buffered, then 
sent to the sound card.
It seems to work fine for some time, then the error 10053 appears.
What I'm doing wrong?

Thanks in advance.

Lapo

-------------------------------

this is the snip of the code

SERVER SIDE:
when a 1000 bytes chunk arrives, Data point to the buffer and BytesReaded is 
the size (usually 1000)
if(TCPLive->Socket->ActiveConnections>0) {
  for(int i=0;i<TCPLive->Socket->ActiveConnections;i++) {
   TCustomWinSocket *Client=TCPLive->Socket->Connections[i];
    if(Client!=NULL) {
      try {
        if(Client->Connected) {
          Client->SendBuf(Data, BytesReaded);
        }
      }
      catch(Exception &e) {
        LogLine("Error sending to "+Client->RemoteHost+": "+e.Message);
      }
    }
  }
}


CLIENT SIDE:
TLiveBuffer is a simple class with two members: BufferSize with the buffer 
length and Buffer that will point to a membuffer.
TLiveWaveOut is a class that read TLiveBuffer list, send to the soundcard 
and free the buffers.

void __fastcall TForm1::TCPRead(TObject *Sender, TCustomWinSocket *Socket)
{
  int BuffersCount=0;
  int len=Socket->ReceiveLength();

  if(len>=LiveWaveOut->BufferSize)
    len=LiveWaveOut->BufferSize;

  char *buffer=new char[len];
  char *subbuffer=buffer;

  try {
    Socket->ReceiveBuf(buffer, len);

    TList *Buffers=BuffersList->LockList();
    try {
      while(len>0) {
        TLiveBuffer *Chunk=new TLiveBuffer;
        if(len>=LiveWaveOut->BufferSize) {
          Chunk->BufferSize=LiveWaveOut->BufferSize;
          Chunk->Buffer=new char [LiveWaveOut->BufferSize];
          memcpy(Chunk->Buffer, subbuffer, LiveWaveOut->BufferSize);
        }
        else {
          Chunk->BufferSize=len;
          Chunk->Buffer=new char [Chunk->BufferSize];
          memcpy(Chunk->Buffer, subbuffer, Chunk->BufferSize);
        }
        BuffersCount=Buffers->Add(Chunk);
        len-=Chunk->BufferSize;
        subbuffer+=Chunk->BufferSize;
      }
    }
    __finally {
      BuffersList->UnlockList();
    }

  }
  __finally {
    delete buffer;
  }
}

Re: TServerSocket/TClientSocket send buffer error 10053 and 10057

#773

Author: Remy Lebeau (TeamB)
Date: Mon, 29 Oct 2007 16:55

41 lines
2888 bytes

"newsgroups.borland.com" <lapoguidi@alice.it> wrote in message 
news:4724bebc@newsgroups.borland.com...

> I have a TServerSocket in non-blocking listening on port 5678.

Is the client running in blocking or non-blocking mode?

> It seems to work fine for some time, then the error 10053 appears.

On which side?  The client or the server?

> What I'm doing wrong?

You are not using the return value of SendBuf() on the server side, or the 
return value of ReceiveBuf() on the client side.

The server is non-blocking, so you need to use its OnWrite event when 
blocking transmissions occur.  When SendBuf() returns -1 without raising an 
exception or generating an OnError event, you have to buffer the data you 
were trying to send at the time and then re-send it when the OnWrite event 
is triggered at a later time.  You have to do that on a per-connection 
basic, so I suggest you make use of TCustomWinSocket's Data property for 
that.  One thing you could do is store a TMemoryStream object in that 
property, and then cache the data when needed.  Please go to 
http://www.deja.com and search through the newsgroup archives.  I've posted 
examples of this several times before.

You are also not checking the return value of ReceiveLength() on the client 
side for values less than 1.  If your client is running in non-blocking 
mode, then multiple packets can trigger multiple OnRead events.  However, 
your reading in the first event may receive all of the available data from 
both events, leaving nothing for the second event to read.  So you need to 
account for that possibility.

Alternatively, you might consider switching to a UDP-based protocol, such as 
MultiCasting or RTP, instead of trying to use TCP for real-time 
broadcasting.  TCP is not really designed for that.


Gambit

Re: TServerSocket/TClientSocket send buffer error 10053 and 10057

#776

Author: newsgroups.borland.com
Date: Tue, 30 Oct 2007 11:47

10 lines
1467 bytes

I would like to thank you.
As usual you're driving me to the right way.

I'll try to search on deja.com and I'll try to inform myself better on 
Multicasting or RTP...
Have you some tips about them?

Thanks again.

Lapo

Re: TServerSocket/TClientSocket send buffer error 10053 and 10057

#777

Author: newsgroups.borland.com
Date: Tue, 30 Oct 2007 11:59

19 lines
1931 bytes

> Is the client running in blocking or non-blocking mode?
Client is also in non-blocking mode

> On which side?  The client or the server?
Error 10053 appears on client side, then error 10057 appears on server side

> You are not using the return value of SendBuf() on the server side...
Thanks for the tip, I'll try to solve also reading your samples on deja.com


> Alternatively, you might consider switching to a UDP-based protocol, such 
> as MultiCasting or RTP, instead of trying to use TCP for real-time 
> broadcasting.  TCP is not really designed for that.
Have you some input about Multicasting or RTP protocols?
I can't open port on firewalls at client side. They need opened port?

Thanks.

Lapo

Re: TServerSocket/TClientSocket send buffer error 10053 and 10057

#778

Author: Colin B Maharaj
Date: Fri, 02 Nov 2007 11:14

21 lines
1841 bytes

You can still use TCP with it's UDP counterpart.
The TCP Clients will indicate to the server who has
connected to your server and the server can then
do the broadcast to the UDP counterparts that are
open on the clients.

That way you will still have a "connection" to your
server since using pure UDP you will not really be
able to properly track who is "listening in" or not.

newsgroups.borland.com wrote:
> I would like to thank you.
> As usual you're driving me to the right way.
> 
> I'll try to search on deja.com and I'll try to inform myself better on 
> Multicasting or RTP...
> Have you some tips about them?
> 
> Thanks again.
> 
> Lapo

Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads