| Author |
Socket:Packet Size
|
|
|
| Hi friends.............
While sending and receiving file through TCP/UDP Socket.....
Im using send/sendto and recv/recvfrom.............with buffer size of
MAXLINE=4095...........It does mean thai i want to send the data in my
packet of the same size..................
But i m not successful in this...........
Some times it is sending 1 byte n other time
24........46.............87........Really im not getting this !
Actual problem with me is that.......I want to know how can i send
specified no of bytes in my PACKET (TCP/UDP)
Regards
YASH
| |
| David Schwartz 2005-07-19, 7:49 am |
|
"Yash" <yash_mbm@yahoo.com> wrote in message
news:1121774324.797347.285980@f14g2000cwb.googlegroups.com...
> While sending and receiving file through TCP/UDP Socket.....
> Im using send/sendto and recv/recvfrom.............with buffer size of
> MAXLINE=4095...........It does mean thai i want to send the data in my
> packet of the same size..................
> But i m not successful in this...........
> Some times it is sending 1 byte n other time
> 24........46.............87........Really im not getting this !
>
> Actual problem with me is that.......I want to know how can i send
> specified no of bytes in my PACKET (TCP/UDP)
You can't. Neither TCP nor UDP gives the application direct control over
the size of the packets sent. Why do you care? They will use whatever size
packets they need to make sure the data that comes out one end is the same
as the data that goes in the other. (Except UDP is lossy and may duplicate
or re-order.)
DS
| |
| Asbjørn Sæbø 2005-07-19, 7:49 am |
| "Yash" <yash_mbm@yahoo.com> writes:
> Hi friends.............
>
> While sending and receiving file through TCP/UDP Socket.....
> Im using send/sendto and recv/recvfrom.............with buffer size of
> MAXLINE=4095...........It does mean thai i want to send the data in my
> packet of the same size..................
> But i m not successful in this...........
> Some times it is sending 1 byte n other time
> 24........46.............87........Really im not getting this !
> [...]
Sorry, no answer to your question.
But may I suggest that you buy a new keyboard? It seems that the "."
key is (partly) stuck on the one you have now. ;-)
Asbj.S.
| |
|
| Thanks for ur suggestion........I read this thing in W. Richard Stevens
book also.............
But is it not that bandwith is wasted because.............for eg. take
my case.........
Im having 3 PCs connected to GigEth Switch.........I m using GigNIC
cards on that......................And in this environment sometimes my
application is sending only ONE BYTE in a PACKET..............
If i cant control packet size than who can i control throughput of my
network.
| |
|
| Thanks for ur suggestion........I read this thing in W. Richard Stevens
book also.............
But is it not that bandwith is wasted because.............for eg. take
my case.........
Im having 3 PCs connected to GigEth Switch.........I m using GigNIC
cards on that......................And in this environment sometimes my
application is sending only ONE BYTE in a PACKET..............
If i cant control packet size than who can i control throughput of my
network.
| |
|
| Thanks for ur suggestion........I read this thing in W. Richard Stevens
book also.............
But is it not that bandwith is wasted because.............for eg. take
my case.........
Im having 3 PCs connected to GigEth Switch.........I m using GigNIC
cards on that......................And in this environment sometimes my
application is sending only ONE BYTE in a PACKET..............
If i cant control packet size than who can i control throughput of my
network.
| |
|
| Thanks for ur suggestion........I read this thing in W. Richard Stevens
book also.............
But is it not that bandwith is wasted because.............for eg. take
my case.........
Im having 3 PCs connected to GigEth Switch.........I m using GigNIC
cards on that......................And in this environment sometimes my
application is sending only ONE BYTE in a PACKET..............
If i cant control packet size than who can i control throughput of my
network.
| |
| Ulrich Hobelmann 2005-07-19, 5:54 pm |
| Asbjørn Sæbø wrote:
> But may I suggest that you buy a new keyboard? It seems that the "."
> key is (partly) stuck on the one you have now. ;-)
Not only '.', the send key also seems stuck (or auto-fire?).
--
XML is a prime example of retarded innovation.
-- Erik Meijer and Peter Drayton, Microsoft Corporation
| |
| David Schwartz 2005-07-19, 5:54 pm |
|
"Yash" <yash_mbm@yahoo.com> wrote in message
news:1121778148.494175.118450@g47g2000cwa.googlegroups.com...
> Thanks for ur suggestion........I read this thing in W. Richard Stevens
> book also.............
> But is it not that bandwith is wasted because.............for eg. take
> my case.........
> Im having 3 PCs connected to GigEth Switch.........I m using GigNIC
> cards on that......................And in this environment sometimes my
> application is sending only ONE BYTE in a PACKET..............
> If i cant control packet size than who can i control throughput of my
> network.
For TCP, pass as many bytes as possible in each call to 'send' or
'write' or whatever function you're using. If necessary, write your own
buffering code with a 'flush' function when your done.
DS
| |
|
| Thanks Devid !
But if we cant control the packet size..............than ahat is the
meaning/significance of frame size of 64,512,4096 bytes.
How do they make sense for application developer..............as i m
having control over application buffer only...............but the
actual transmission is through..send/receive socket calls, where kernal
makes decesion what packet size to be sent.
| |
| Rainer Temme 2005-07-21, 7:48 am |
| Yash wrote:
> Im having 3 PCs connected to GigEth Switch.........I m using GigNIC
> And in this environment sometimes my
> application is sending only ONE BYTE in a PACKET..............
So what ???
Do you think this single byte of application data is transported by
a packet of MTU size ???
(MTU being the maximum transport unit)
Sending single bytes is ok if it cannot be avoided...for a
tcp-connection, this results in an IP-packet of 41bytes...
20bytes IP header + 20 bytes TCP header + 1 byte application data.
(the headers might be larger by multiples of 4 if options are
present)
As you see, the ration between the envelope (headers) and application
data is undesirably bad in this case ... but still ok if your
application needs to send the byte "now" and there is no more
data to be sent "now".
You might want to read about a thing called "Nagle Algorythm".
That's TCP's answer to your question about the waste of
bandwith. In some cases (but only in very few really) it
can be clever to switch Nagle off...most time nagle
does a very good job and maintains an acceptable
bandwidth even for applications which write everything
bytewise.
Regards ... Rainer
| |
| David Schwartz 2005-07-21, 6:02 pm |
|
"Yash" <yash_mbm@yahoo.com> wrote in message
news:1121939611.156434.179800@f14g2000cwb.googlegroups.com...
> Thanks Devid !
> But if we cant control the packet size..............than ahat is the
> meaning/significance of frame size of 64,512,4096 bytes.
I'm not sure what you mean. What is a "frame size"?
> How do they make sense for application developer..............as i m
> having control over application buffer only...............but the
> actual transmission is through..send/receive socket calls, where kernal
> makes decesion what packet size to be sent.
I still don't understand your question. You make send calls, and the
data comes out in receive calls. You are guaranteed that the other end will
get the same bytes in the same order but not in the same chunk size. That's
the nature of TCP, and if that's not what you want, don't use TCP.
DS
|
|
|
|