Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Networking and C++ question
83 views
Skip to first unread message
woodb...@gmail.com
Apr 26, 2015, 6:18:06 PM4/26/15
to
http://stackoverflow.com/questions/29882666/c-socket-programming-read-write
Is limiting the size of the read the problem as EJP suggests?
I was thinking it might have to do with the OP's assuming int is 4 bytes.
I have a C++ library that helps with transferring files between
clients and server -- http://webEbenezer.net/build_integration.html
Brian
Ebenezer Enterprises - "America did not create religious
liberty, religious liberty created America." Bobby Jindal
http://webEbenezer.net
Ian Collins
Apr 26, 2015, 7:32:17 PM4/26/15
to
woodb...@gmail.com wrote:
>
>
> http://stackoverflow.com/questions/29882666/c-socket-programming-read-write
>
> Is limiting the size of the read the problem as EJP suggests?
> I was thinking it might have to do with the OP's assuming int is 4 bytes.
I often wonder why people compile scungy C as C++...
>
>
> http://stackoverflow.com/questions/29882666/c-socket-programming-read-write
>
> Is limiting the size of the read the problem as EJP suggests?
> I was thinking it might have to do with the OP's assuming int is 4 bytes.
There are a number of possible mistakes in the code, assuming the file
size will fit in an int would be more of a problem than assuming
sizeof(int).
--
Ian Collins
Scott Lurndal
Apr 27, 2015, 9:29:26 AM4/27/15
to
woodb...@gmail.com writes:
>
>
>http://stackoverflow.com/questions/29882666/c-socket-programming-read-write
>
>Is limiting the size of the read the problem as EJP suggests?
>I was thinking it might have to do with the OP's assuming int is 4 bytes.
Don't see how this has anything to do with C++. One must
>
>
>http://stackoverflow.com/questions/29882666/c-socket-programming-read-write
>
>Is limiting the size of the read the problem as EJP suggests?
>I was thinking it might have to do with the OP's assuming int is 4 bytes.
first understand the nature of TCP (stream, not packet) and
interactions with blocking (or non-blocking) behavior.
>
>I have a C++ library that helps with transferring files between
>
Ah, never mind. You're advertising your product. Shame on you.
woodb...@gmail.com
Apr 27, 2015, 11:06:55 AM4/27/15
to
On Monday, April 27, 2015 at 8:29:26 AM UTC-5, Scott Lurndal wrote:
>
> Don't see how this has anything to do with C++. One must
> first understand the nature of TCP (stream, not packet) and
> interactions with blocking (or non-blocking) behavior.
It may not be using a lot of new features, but it's C++.
>
> Don't see how this has anything to do with C++. One must
> first understand the nature of TCP (stream, not packet) and
> interactions with blocking (or non-blocking) behavior.
>
> Ah, never mind. You're advertising your product. Shame on you.
Brian
Ebenezer Enterprises - "But realize this, that in the last days
difficult times will come. For men will be lovers of self,
lovers of money, boastful, arrogant, revilers, disobedient to
parents, ungrateful, unholy, unloving, irreconcilable,
malicious gossips, without self-control, brutal, haters of good"
2nd Timothy 3:2
http://webEbenezer.net
Drew Lawson
Apr 27, 2015, 11:28:27 AM4/27/15
to
In article <888a30f1-b148-4b1f...@googlegroups.com>
uint32_t and normalize it with htonl()/ntohl().
I didn't read through the loops carefully. No comments combined
with single-letter variable names makes my brain bleed.
Were I debugging that, I'd compare the received file with the
original. That would suggest what the problem is. (Well, I'd also
split stuff out into sendMessage() and receiveMessage() or such.)
--
Drew Lawson
I only came in search of answers, never planned to sell my soul
I only came in search of something left that I could call my own
woodb...@gmail.com writes:
>
>
>http://stackoverflow.com/questions/29882666/c-socket-programming-read-write
>
>Is limiting the size of the read the problem as EJP suggests?
>I was thinking it might have to do with the OP's assuming int is 4 bytes.
I use a similar protocol for messaging, but I specify the size as
>
>
>http://stackoverflow.com/questions/29882666/c-socket-programming-read-write
>
>Is limiting the size of the read the problem as EJP suggests?
>I was thinking it might have to do with the OP's assuming int is 4 bytes.
uint32_t and normalize it with htonl()/ntohl().
I didn't read through the loops carefully. No comments combined
with single-letter variable names makes my brain bleed.
Were I debugging that, I'd compare the received file with the
original. That would suggest what the problem is. (Well, I'd also
split stuff out into sendMessage() and receiveMessage() or such.)
--
Drew Lawson
I only came in search of answers, never planned to sell my soul
I only came in search of something left that I could call my own
Scott Lurndal
Apr 27, 2015, 1:03:59 PM4/27/15
to
woodb...@gmail.com writes:
>On Monday, April 27, 2015 at 8:29:26 AM UTC-5, Scott Lurndal wrote:
>>
>> Don't see how this has anything to do with C++. One must
>> first understand the nature of TCP (stream, not packet) and
>> interactions with blocking (or non-blocking) behavior.
>
>It may not be using a lot of new features, but it's C++.
>
The problem being discussed in the example you posted
>On Monday, April 27, 2015 at 8:29:26 AM UTC-5, Scott Lurndal wrote:
>>
>> Don't see how this has anything to do with C++. One must
>> first understand the nature of TCP (stream, not packet) and
>> interactions with blocking (or non-blocking) behavior.
>
>It may not be using a lot of new features, but it's C++.
>
is related to network protocols, specifically to TCP, more specifically
regarding the misconception that some programmers have about
the preservation of message boundaries in a stream-based
protocol and how IO_NONBLOCK changes the behavior of
system calls accessing the stream.
The fact that the example was written in C++ is unrelated
to the problem being discussed.
The write answer, is to use sendfile(2) :-).
woodb...@gmail.com
Apr 27, 2015, 3:34:35 PM4/27/15
to
On Monday, April 27, 2015 at 12:03:59 PM UTC-5, Scott Lurndal wrote:
>
> The write answer, is to use sendfile(2) :-).
I entered "sendfile compression" without the quotes into
>
> The write answer, is to use sendfile(2) :-).
https://duckduckgo.com and it came back with: "Did you mean
send file compression?" It put a space between send and file.
And when I search the sendfile man page for compression, I
get "Pattern not found." Compression is important for what
I'm working on.
Brian
Ebenezer Enterprises - In G-d we trust.
http://webEbenezer.net
Ian Collins
Apr 28, 2015, 4:29:16 AM4/28/15
to
woodb...@gmail.com wrote:
> On Monday, April 27, 2015 at 12:03:59 PM UTC-5, Scott Lurndal wrote:
>
>>
>> The write answer, is to use sendfile(2) :-).
>
> I entered "sendfile compression" without the quotes into
> https://duckduckgo.com and it came back with: "Did you mean
> send file compression?" It put a space between send and file.
> And when I search the sendfile man page for compression, I
> get "Pattern not found." Compression is important for what
> I'm working on.
So use compression on your connection. sendfile(2) is exactly what the
> On Monday, April 27, 2015 at 12:03:59 PM UTC-5, Scott Lurndal wrote:
>
>>
>> The write answer, is to use sendfile(2) :-).
>
> I entered "sendfile compression" without the quotes into
> https://duckduckgo.com and it came back with: "Did you mean
> send file compression?" It put a space between send and file.
> And when I search the sendfile man page for compression, I
> get "Pattern not found." Compression is important for what
> I'm working on.
original scungy C code was trying to emulate.
--
Ian Collins
woodb...@gmail.com
Apr 28, 2015, 11:21:34 AM4/28/15
to
On Tuesday, April 28, 2015 at 3:29:16 AM UTC-5, Ian Collins wrote:
for others. It looks like ICE has support for that:
https://doc.zeroc.com/display/Ice/Protocol+Compression
The C++ Middleware Writer (CMW) doesn't have support for that
yet, but it's something that I'd like to add. My middle
tier sends 3 types of messages to the CMW: a login message,
a keepalive message and a generate message. Ideally the login
and keepalive messages wouldn't be compressed.
As the ICE page mentions, small messages are poor candidates
for compression. Using compression on such messages has
the opposite of the desired effect: rather than saving on
bandwidth, you wind up using more. Why pay for compression
and bandwidth that you don't need?
Brian
Ebenezer Enterprises - So far G-d has helped us.
http://webEbenezer.net
> woodb...@gmail.com wrote:
> >
> > I entered "sendfile compression" without the quotes into
> > https://duckduckgo.com and it came back with: "Did you mean
> > send file compression?" It put a space between send and file.
> > And when I search the sendfile man page for compression, I
> > get "Pattern not found." Compression is important for what
> > I'm working on.
>
> So use compression on your connection.
You may want compression for some messages but not
> >
> > I entered "sendfile compression" without the quotes into
> > https://duckduckgo.com and it came back with: "Did you mean
> > send file compression?" It put a space between send and file.
> > And when I search the sendfile man page for compression, I
> > get "Pattern not found." Compression is important for what
> > I'm working on.
>
> So use compression on your connection.
for others. It looks like ICE has support for that:
https://doc.zeroc.com/display/Ice/Protocol+Compression
The C++ Middleware Writer (CMW) doesn't have support for that
yet, but it's something that I'd like to add. My middle
tier sends 3 types of messages to the CMW: a login message,
a keepalive message and a generate message. Ideally the login
and keepalive messages wouldn't be compressed.
As the ICE page mentions, small messages are poor candidates
for compression. Using compression on such messages has
the opposite of the desired effect: rather than saving on
bandwidth, you wind up using more. Why pay for compression
and bandwidth that you don't need?
Brian
Ebenezer Enterprises - So far G-d has helped us.
http://webEbenezer.net
woodb...@gmail.com
May 9, 2015, 2:41:58 PM5/9/15
to
Turning the page now to another networking and C++ question.
I was reading here
http://www.gamedev.net/topic/668188-udp-sockets-size-and-speed-question/
"the 'bandwidth delay product' is an important quantity; most simple
socket programs do not set a big enough send or receive buffer for
optimal throughput on modern networks for example."
And this page
http://www.psc.edu/index.php/networking/641-tcp-tune -- says
"In the future, we hope to see all TCP implementations support
autotuning with appropriate defaults for other options, making
this website largely obsolete."
I kind of have sinking feeling after having dealt with a few
other things over the years that at least one of FreeBSD, Linux
or Windows will not have support for autotuning and that that
page is far from obsolete.
Then I was thinking about the setpriority function in relation to
this sort of thing. It would be nice if setpriority went beyond
cpu and extended to memory use. But I didn't find much about
that while doing some searching. To me the general case would
be that you want to give a process priority over others and that
would include both cpu and memory. So a call to setpriority would
be all that's needed -- or at least reduce the likelihood that
you also need to set the size of send and receive socket buffers.
Can I get a witness?
Brian
Ebenezer Enterprises - "Unless the L-rd builds the house,
they labor in vain that build it." Psalms 127:1
http://webEbenezer.net
I was reading here
http://www.gamedev.net/topic/668188-udp-sockets-size-and-speed-question/
"the 'bandwidth delay product' is an important quantity; most simple
socket programs do not set a big enough send or receive buffer for
optimal throughput on modern networks for example."
And this page
http://www.psc.edu/index.php/networking/641-tcp-tune -- says
"In the future, we hope to see all TCP implementations support
autotuning with appropriate defaults for other options, making
this website largely obsolete."
I kind of have sinking feeling after having dealt with a few
other things over the years that at least one of FreeBSD, Linux
or Windows will not have support for autotuning and that that
page is far from obsolete.
Then I was thinking about the setpriority function in relation to
this sort of thing. It would be nice if setpriority went beyond
cpu and extended to memory use. But I didn't find much about
that while doing some searching. To me the general case would
be that you want to give a process priority over others and that
would include both cpu and memory. So a call to setpriority would
be all that's needed -- or at least reduce the likelihood that
you also need to set the size of send and receive socket buffers.
Can I get a witness?
Brian
Ebenezer Enterprises - "Unless the L-rd builds the house,
they labor in vain that build it." Psalms 127:1
http://webEbenezer.net
0 new messages