Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

TServerSocket/TClientSocket send buffer error 10053 and 10057

191 views
Skip to first unread message

newsgroups.borland.com

unread,
Oct 28, 2007, 12:54:01 PM10/28/07
to
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;
}
}

Remy Lebeau (TeamB)

unread,
Oct 29, 2007, 12:55:38 PM10/29/07
to

"newsgroups.borland.com" <lapo...@alice.it> wrote in message
news:4724...@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


newsgroups.borland.com

unread,
Oct 30, 2007, 7:47:15 AM10/30/07
to
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

newsgroups.borland.com

unread,
Oct 30, 2007, 7:59:21 AM10/30/07
to
> 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

Colin B Maharaj

unread,
Nov 2, 2007, 7:14:13 AM11/2/07
to
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.

0 new messages