Socket questions

[Guest]

Greetings to everyone

I'm currently developing a client/server socket library (a bit like TcpClient/TcpListener), using both Udp and Tcp, and I have a couple of points which are still of yet unclear
- is it possible for a socket connection to, simultaneously receive and send with the same client ? Namely, if I have called a receive function (Socket.BeginReceive for instance), is it safe to call a BeginSend after that ? What will happen if data comes at that moment ? I don't know enough about sockets to clear this ; from empirical tests, it seems that simultaneous send/receive is possible between Client A and Client B, but I haven't been able to clear this

- is there a maximum send size for a Tcp socket ? Udp has a max packet size of 64 KB, is there such a limit for Tcp (namely, do I have to fragment data when sending it) or not

Thanks for any answer !

 

[Chad Z. Hower aka Kudzu]

I'm currently developing a client/server socket library (a bit like
TcpClient/TcpListener), using both Udp and Tcp, and I have a couple of
points which are still of yet unclear : - is it possible for a socket
connection to, simultaneously receive and send with the same client ?

Yes - but what is the definition of simultaneous in this context? Threads?
Per connection?

Namely, if I have called a receive function (Socket.BeginReceive for
instance), is it safe to call a BeginSend after that ? What will happen
if data comes at that moment ? I don't know enough about sockets to

Im not sure about that particular interface, but it is safe for sockets and I
would assume that this interface permits it as well.

- is there a maximum send size for a Tcp socket ? Udp has a max packet

TCP has no maximum size. Are you sure you understand how TCP works? Its a
stream protocol, not a packet protocol.

size of 64 KB, is there such a limit for Tcp (namely, do I have to
fragment data when sending it) or not ?

No, TCP automatically splits data internally. UDP cannot realistically handle
64k, thats just what your local network reports. In practice it will not
work. You need to keep UDP at 8k, or even more relibaly 1k per packet.

Are you committed to using TCPClient/TCPListener classes?


--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"


ELKNews - Get your free copy at http://www.atozedsoftware.com

 

[Guest]

Yes - but what is the definition of simultaneous in this context? Threads?

Per connection?

Per connection yes - would client A and client B be able to do receive and send at the same time between them.

Im not sure about that particular interface, but it is safe for sockets and I
would assume that this interface permits it as well.

Perfect, that's what I was hoping

TCP has no maximum size. Are you sure you understand how TCP works? Its a
stream protocol, not a packet protocol.

I don't understand TCP much that's the problem (I wish I had paid more attention in school) ...
I should have remembered the Stream I wrote in the constructor wasn't just for decoration (sic)

No, TCP automatically splits data internally. UDP cannot realistically handle
64k, thats just what your local network reports. In practice it will not
work. You need to keep UDP at 8k, or even more relibaly 1k per packet.

I'm keeping it a 1k yes, heard about what it gave in practice too when I started the class.

Are you committed to using TCPClient/TCPListener classes?

Actually I was just giving this as an exemple : I'm trying to do the same thing with the Socket class as a foundation, only having a class with an asynchronous behavior (TcpClient/Listener is synchronous).

Thanks a lot for all the help, it's a lifesaver ...

 

[Chad Z. Hower aka Kudzu]

Per connection yes - would client A and client B be able to do receive
and send at the same time between them.

Yes, but according to the .net docs, the .net classes do not support it. My
thoery is it migth work, but then maybe not..

The sockets DO support it.

My recommedation is use Indy. I know it supports it. Its free, widely used,
well maintained and well supported. The .net docs arent available yet, but
its really easy to use and there is a lot of support for it.

http://www.indyproject.org/indy.html

Perfect, that's what I was hoping

Unfortunately I've been told that the .net docs say that the class is not
safe this way.

Actually I was just giving this as an exemple : I'm trying to do the
same thing with the Socket class as a foundation, only having a class
with an asynchronous behavior (TcpClient/Listener is synchronous).

Why asynchronous?


--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"


ELKNews - Get your free copy at http://www.atozedsoftware.com

 

[Guest]

Yes, but according to the .net docs, the .net classes do not support it. My

thoery is it migth work, but then maybe not..

Damn ... that's a tough one.
For the moment I set up a blocking event used by both the receive handler and the send handler, haven't tested it yet to see if it worked though.

My recommedation is use Indy. I know it supports it. Its free, widely used,
well maintained and well supported. The .net docs arent available yet, but
its really easy to use and there is a lot of support for it.

That seems so much better that's it's not funny ><
If it was my project I'd do that instantly - unfortunately my boss doesn't want me to use any library external to .NET ...
Thanks for the link though, I'll use it for myself

Why asynchronous?

Well 2 main reasons :
1/ TcpListener family is blocking, so there would be little need to reinvent the wheel - it would end up the same but worse (I just added the ability to autofragment heavy data so that it can be sent more or less safely through Udp)
2/ Not blocking the caller after a call was one of my requirements ... I ended up with an asynchronous model, transmitting data through events. Definitely not a stellar design ...

Thanks again for the answer, I'm learning something new with every one of your emails !

 

[Chad Z. Hower aka Kudzu]

That seems so much better that's it's not funny ><
If it was my project I'd do that instantly - unfortunately my boss
doesn't want me to use any library external to .NET ... Thanks for the
link though, I'll use it for myself

Wow. Tough restrictions to not use ANY external stuff. But do keep the link
for yourself. We are doing new builds today and are forming the VS demo team
to make demos in VB and C#. Docs are in the process of being converted to
intellisense format.

less safely through Udp) 2/ Not blocking the caller after a call was one
of my requirements ... I ended up with an asynchronous model,
transmitting data through events. Definitely not a stellar design ...

You can block and thread - it really depends on your needs but usually this
is better.

Thanks again for the answer, I'm learning something new with every one
of your emails !

Thanks.


--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"


ELKNews - Get your free copy at http://www.atozedsoftware.com

 

[Gaurav Khanna [C# MVP]]

Hi!

Another way to maintain non-blocking behaviour is that when the "Pending" is
true, accept the sock/TcpClient and spawn a new thread (or queue to the
ThreadPool), sending the accepted Socket/TcpClient object for it to process.
The parent, which is listening for incoming requests, will not block.

--
Regards,
Kumar Gaurav Khanna
-----------------------------------------------------------------
Microsoft MVP - C#/.NET, MCSE Windows 2000/NT4, MCP+I
WinToolZone - Spelunking Microsoft Technologies
http://www.wintoolzone.com/
OpSupport - Spelunking Rotor
http://opsupport.sscli.net/
Bangalore .NET Users' Group
http://groups.msn.com/bdotnet/

Damn ... that's a tough one.
For the moment I set up a blocking event used by both the receive handler

and the send handler, haven't tested it yet to see if it worked though.

That seems so much better that's it's not funny ><
If it was my project I'd do that instantly - unfortunately my boss doesn't

want me to use any library external to .NET ...

Thanks for the link though, I'll use it for myself


Well 2 main reasons :
1/ TcpListener family is blocking, so there would be little need to

reinvent the wheel - it would end up the same but worse (I just added the
ability to autofragment heavy data so that it can be sent more or less
safely through Udp)

2/ Not blocking the caller after a call was one of my requirements ... I

ended up with an asynchronous model, transmitting data through events. Defin
itely not a stellar design ...

Thanks again for the answer, I'm learning something new with every one of

your emails !

 

[Chad Z. Hower aka Kudzu]

Another way to maintain non-blocking behaviour is that when the
"Pending" is true, accept the sock/TcpClient and spawn a new thread (or
queue to the ThreadPool), sending the accepted Socket/TcpClient object
for it to process. The parent, which is listening for incoming requests,
will not block.

Which is slower than what I suggested, and why I didnt suggest it.

He seems to be in a very tight situation and needs all the speed he can get.


--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"


ELKNews - Get your free copy at http://www.atozedsoftware.com