Sunday, April 3, 2016

Digest for comp.lang.c++@googlegroups.com - 18 updates in 8 topics

bleachbot <bleachbot@httrack.com>: Apr 03 02:10AM +0200

bleachbot <bleachbot@httrack.com>: Apr 03 02:12AM +0200

bleachbot <bleachbot@httrack.com>: Apr 04 12:36AM +0200

bleachbot <bleachbot@httrack.com>: Apr 04 12:48AM +0200

Ramine <ramine@1.1>: Apr 03 06:37PM -0700

Hello...........
 
 
I will a little bit explain my USL program...
 
If you have took a look at this link:
 
https://cran.r-project.org/web/packages/usl/vignettes/usl.pdf
 
You will notice that the performance data for the raytracer
in the link above is the same as the performance data
inside the data.csv file inside my zip file of my USL software..
 
And as you have noticed in the link above the peak scalability
number is at: 449 processors.
 
So if you run my program against this same performance data
like this at the command prompt:
 
usl data.csv
 
So the output is of my program is:
 
--
Peak number is: 449.188
Predicted scalability peak is: 18.434
Coefficient of determination R-squared is: 0.995
--
 
So as you have noticed that the peak number that
is the peak number of processors is: 449.188
this is the same result as the link above.
 
So my program is working correctly.
 
But this is not the end of the story..
 
You have to optimize the criterion of the cost for a better QoS,
and for this i have supplied you with a second option
called -d that you have to run for that, so you have
to type at the command prompt:
 
usl data.csv -d 0.3 0.1
 
 
the 0.3 is the slop of the secant with a step 0.1,
so since the step is 0.1 so this will approximate
a derivative of the USL equation that equal 0.3,
so here is the output of my program when you run
it with -d 0.3 0.1:
 
--
Peak number is: 449.188
Predicted scalability peak is: 18.434
Coefficient of determination R-squared is: 0.995
The derivative of the USL equation at delta(y)/delta(x)=0.300 with a
step delta(x)=0.100, gives a good approximation of a number and a
derivative delta(y)/delta (x) of: 16.600 and 0.300
--
 
So as you have noticed that a good approximation for the
derivative of the USL equation will arrive at the 16.600 cores
and this gives also a derivative of the secant that approximate the
derivative of the USL equation.
 
So to optimize more the criterion of the cost for a better QoS,
you have to choose a good delta(y)/delta(x) to optimize the criterion of
the cost of your system and you have to balance better between the
performance and the cost.
 
You can download my USL program with the source code from:
 
https://sites.google.com/site/aminer68/universal-scalability-law-for-delphi-and-freepascal
 
 
 
Thank you,
Amine Moulay Ramdane.
Ramine <ramine@1.1>: Apr 03 06:49PM -0700

On 4/3/2016 6:37 PM, Ramine wrote:
> to type at the command prompt:
 
> usl data.csv -d 0.3 0.1
 
> the 0.3 is the slop of the secant with a step 0.1,
 
I mean: the 0.3 is the slope of the secant with a step 0.1
 
elmazzun <mazzocchiandrea24@gmail.com>: Apr 03 01:00PM -0700

My proxy HTTPS, dealing with `CONNECT` HTTP requests from client, manages to connect immediately to the requested remote server after:
 
1. opening a socket to remote server;
2. setting the socket to non blocking mode;
3. attempting `connect()` checking for `if ((connect_res == -1) && (errno != EINPROGRESS))`;
4. looping with `select()` checking if server socket is ready to send or receive data in the following way:
 
if ((conn_res == -1) && (errno != EINPROGRESS)) {
do {
FD_ZERO(&rdset);
FD_SET(sockfd_server, &rdset);
wrset = rdset;
tv.tv_sec = 0;
tv.tv_usec = 0;
select_res = select(sockfd_server+1, &rdset, &wrset, NULL, &tv);
} while ((select_res == -1) && (errno == EINTR));
printf("connection OK\n");
} else {
printf("connected immediately\n");
}
 
5. setting socket back to blocking mode;
 
6. sending `"HTTP/1.1 200 Connection established\r\n"`to the client after successfull `connect()`.
 
 
Now I should be ready to forward data from client to server and from server to client when data are available from one of the two sides of connection, but it never succeeds.
 
Here's the code that should forward data from both sides of connection:
 
void proxyHTTPS(int new_sockfd_client, int sockfd_server) {

printf("starting proxyHTTPS\n");
fd_set fdset;
int maxp1 = sockfd_server > new_sockfd_client ? sockfd_server+1 : new_sockfd_client+1;
int r;
int read_from_client = 0;
int read_from_server = 0;
int send_to_client = 0;
int send_to_server = 0;
struct timeval timeout;
char https_buf[4096];
int https_buf_size = sizeof(https_buf);
memset(https_buf, 0, https_buf_size);
// tried 0, 5, 10, 20, 30, 60 seconds timeout,
// still got this problem
timeout.tv_sec = 10;
timeout.tv_usec = 0;
 
while (true) {
FD_ZERO(&fdset);
FD_SET(new_sockfd_client, &fdset);
FD_SET(sockfd_server, &fdset);
timeout.tv_sec = 10;
timeout.tv_usec = 0;
 
r = select(maxp1, &fdset, NULL, NULL, &timeout);
 
if (r == -1) {
perror("select()");
break;
}
 
if (r == 0) { // select timed out
printf("proxyHTTPS: select() request timeout 408\n");
break;
}
 
if ((!FD_ISSET(new_sockfd_client, &fdset)) && ((!FD_ISSET(sockfd_server, &fdset)))) {
printf("proxyHTTPS: SELECT sockfd not responding\n");
break;
}
 
else if (FD_ISSET(new_sockfd_client, &fdset)) {
printf("proxyHTTPS: reading from client and sending to server\n");
do {
read_from_client = recv(new_sockfd_client, https_buf, https_buf_size, 0);
if (read_from_client > 0) {
send_to_server = send(sockfd_server, https_buf, read_from_client, 0);
if (send_to_server <= 0) {
printf("proxyHTTPS: failed sending to server\n");
perror("proxyHTTPS send to server:");
break;
}
} else if (read_from_client == 0) {
printf("proxyHTTPS client sent 0 bytes\n");
} else {
perror("proxyHTTPS read from client:");
}
} while (read_from_client > 0);
break;
}
 
else if (FD_ISSET(sockfd_server, &fdset)) {
printf("proxyHTTPS: reading from server and sending to client\n");
do {
read_from_server = recv(sockfd_server, https_buf, https_buf_size, 0);
if (read_from_server > 0) {
send_to_client = send(new_sockfd_client, https_buf, read_from_server, 0);
if (send_to_client <= 0) {
printf("proxyHTTPS: failed sending to client\n");
perror("proxyHTTPS send to client:");
break;
}
} else if (read_from_server == 0) {
printf("proxyHTTPS server sent 0 bytes\n");
} else {
perror("proxyHTTPS read from server:");
}
} while (read_from_server > 0);
break;
}
}
printf("quitting proxyHTTPS\n");
}
 
This is, e.g., a `CONNECT` request the proxy gets from client:
 
CONNECT www.youtube.com:443 HTTP/1.1
Host: www.youtube.com:443
Proxy-Connection: keep-alive
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.110 Safari/537.36
/r/n
 
 
If client sends `CONNECT www.netflix.com:443 HTTP/1.1`, my proxy fails and on terminal prints:
 
setting non block socket
connected immediately
setting block socket
54.228.227.144:443 OK
CONNECT: send to client HTTP/1.1 200 Connection established
starting proxyHTTPS
proxyHTTPS: reading from server and sending to client
proxyHTTPS read from server: Connection refused
quitting proxyHTTPS
 
If clients sends `CONNECT www.youtube.com:443 HTTP/1.1`, my proxy fails again and shows:
 
setting non block socket
connected immediately
setting block socket
216.58.201.238:443 OK
CONNECT: send to client HTTP/1.1 200 Connection established
starting proxyHTTPS
select(): Operation now in progress
proxyHTTPS: select() request timeout 408
quitting proxyHTTPS
 
I think i did all the steps I was told to do in order to establish a tunnel between client and server, `connect()` is always ok, so mistakes must be in my `proxyHTTPS`. I have no clue!
Paavo Helde <myfirstname@osa.pri.ee>: Apr 03 11:42PM +0200

On 3.04.2016 22:00, elmazzun wrote:
> proxyHTTPS: select() request timeout 408
> quitting proxyHTTPS
 
> I think i did all the steps I was told to do in order to establish a tunnel between client and server, `connect()` is always ok, so mistakes must be in my `proxyHTTPS`. I have no clue!
 
There seems to be no C++ code here, are you sure you posted to the right
group? Maybe you wanted a C group, or more probably a networking or
encryption related group (as it seems the problems appear at the
protocol level).
 
If you want to just do some port forwarding, why don't you just use ssh
or some similar tools? And if you want to carry out some
man-in-the-middle attacks in an encrypted channel then it is a good
thing if you do not succeed.
 
Cheers
Paavo
elmazzun <mazzocchiandrea24@gmail.com>: Apr 03 02:49PM -0700

Il giorno domenica 3 aprile 2016 23:42:45 UTC+2, Paavo Helde ha scritto:
> thing if you do not succeed.
 
> Cheers
> Paavo
 
I'm sorry if my question doesn't belong to this group.
I did not want to perform any MITM attack, my proxy would just connect the client to the requested remote server, HTTP or HTTPS.
What would be the right thing to do, apart posting this question in the right group?
Should I cancel this question?
Paavo Helde <myfirstname@osa.pri.ee>: Apr 04 12:15AM +0200

On 3.04.2016 23:49, elmazzun wrote:
> I did not want to perform any MITM attack, my proxy would just connect the client to the requested remote server, HTTP or HTTPS.
> What would be the right thing to do, apart posting this question in the right group?
> Should I cancel this question?
 
Ok, you want to implement an HTTP proxy server. It would be a good start
to say why "ssh -D ..." is not sufficient for your needs. But this has
really nothing to do with C++, so you might get better answers from some
other group with 'networking' or 'socket' in their names.
 
Cheers
Paavo
 
PS. Cancelling something in Usenet is next to impossible.
elmazzun <mazzocchiandrea24@gmail.com>: Apr 03 03:19PM -0700

Sorry, this is the foundation of my thesis, I have to write my own code to implement an HTTP proxy.
Thanks for your advices!
Paavo Helde <myfirstname@osa.pri.ee>: Apr 04 12:47AM +0200

On 4.04.2016 0:19, elmazzun wrote:
> Sorry, this is the foundation of my thesis, I have to write my own code to implement an HTTP proxy.
> Thanks for your advices!
 
If you intend to do this in C++, then I suggest using the Boost.asio
library. This would take care of some platform-specific low-level socket
manipulation and (optionally) multi-threading scalable server
capabilities while leaving the (presumably important for the thesis)
HTTP protocol level programming to you.
 
Of course, if the thesis also involves low-level socket twiddling then
using a library is not an option.
bitrex <bitrex@de.lete.earthlink.net>: Apr 03 05:25PM -0400

So the following code compiles fine under gcc (C++14), to build an array
of squares:
 
#define F4(i) F1((i)), F1((i)+1), F1((i)+2), F1((i)+3)
#define F16(i) F4((i)), F4((i)+4), F4((i)+8), F4((i)+12)
#define F64(i) F16((i)), F16((i)+16), F16((i)+32), F16((i)+48)
#define F256(i) F64((i)), F64((i)+64), F64((i)+128), F64((i)+192)
 
struct Foo {
static constexpr unsigned int bar(char i)
{
return i*i;
}

#define F1(i) blarg(i)
unsigned int baz[256] =
{
F256(0)
};
#undef F1
};
 
Now suppose I wanted the array to be associated only with the
class/struct Foo, not individual instances. If I change the array
declaration to:
 
static const unsigned int baz[256] =
{
F256(0)
};
 
I get an error that the array must be declared "constexpr" for in-class
initialization. So then if I try:
 
static constexpr unsigned int baz[256] =
{
F256(0)
};
 
Nope, can't do that either, because it complains that I'm calling a
"constexpr" within a "constexpr."
 
I'd really only like one copy of the array data to be associated with
the class (i.e. static) and not consume memory for every object
instantiated, as they all require the same data. And I'd like the
contents of the array to be evaluated at compile time via the first
"constexpr."
 
Is there a way to get at what I'm getting at?
bitrex <bitrex@de.lete.earthlink.net>: Apr 03 05:29PM -0400

On 04/03/2016 05:25 PM, bitrex wrote:
> #define F1(i) blarg(i)
 
#define F1(i) bar(i), rather ;-)
Kalle Olavi Niemitalo <kon@iki.fi>: Apr 03 05:20PM +0300


> void (signal(int, void (*)(int)))(int, void (*)(int));
 
> (I hope I got that right;-)
 
Nope, it's void (*signal(int signum, void (*handler)(int)))(int);
Ramine <ramine@1.1>: Apr 02 08:14PM -0700

Hello,
 
I have posted my USL program in this C++ group because
i have included a 32 bit windows executable of my
USL program inside the zip file.
 
You can download it from:
 
https://sites.google.com/site/aminer68/universal-scalability-law-for-delphi-and-freepascal
 
Thank you,
Amine Moulay Ramdane.
Ramine <ramine@1.1>: Apr 02 08:11PM -0700

Hello,
 
 
Universal Scalability Law for Delphi and FreePascal was updated to
version 2.1
 
I think that this new version 2.1 is stable now, i have just
made it robust, so be happy with this very powerful tool.
 
 
You can download it from:
 
 
https://sites.google.com/site/aminer68/universal-scalability-law-for-delphi-and-freepascal
 
How can you be sure that my USL program works correctly ?
 
Please take a look at this link:
 
https://cran.r-project.org/web/packages/usl/vignettes/usl.pdf
 
Notice the raytracer performance data, when they have
analysed it, it gives a peak scalability at: 449
 
So try to run my program inside the zip against
the the same raytracer performance data that
you will find inside the data.csv file inside the zip,
and this will give the same peak scalability at: 449.
 
So as you have noticed, my program is working for this
performance data of the raytracer, so i think that
you can be confident with my program.
 
I have included an executable called usl.exe inside
the zip, please read the readme file to know how
to use it, it is a very powerful tool.
 
 
 
Thank you,
Amine Moulay Ramdane.
Luca Risolia <luca.risolia@linux-projects.org>: Apr 03 01:15AM +0200

Mr Flibble wrote:
> Your absurd habit of writing ::std instead of std continues to irritate
> mate; well done.
 
+1
 
also considering that many people showed him that :: before std is
essentially unuseful.
 
and he also looses potential answers to his questions by obstinately
keeping doing this.
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.

No comments: