we have a Java software to receive and send customer and contracts data from and to our servers. The software runs in a web browser. Sometimes our agents complain about the lag, but it is related to their network connection.
It's our thought to build in some kind of network monitor to show the current network speed. My first thought was it to implement a java version of the Ping program to measure the time before the ping and after the ping. With this information I would have been able to calculate the connection speed. The problem is that Java doesn't support SOCK_RAW type sockets so I can't send ICMP packets. Due to security reasons I can not create some kind of UDP client-server-connection to use UDP sockets. The servers with our customer and contract data is not modifiable due to security reasons so you can't use any sockets at all. In my opinion there doesn't seem to be a convenient way to solve this with Java.
My colleage has another approach. He thought about downloading a picture to measure the download time but this is no good solution to permanently measure the connection speed.
So are there any usable possibilities to measure the connection speed with Java (JSF,JSP) or Javascript (jquery) and embed it on a web site?
To do a good measurement of the network connection, you should probably try and send as much information as possible to see how long it took. A picture would be great, but another approach might be to measure the RTT (Round trip time) to your servers to detect possible latency-related problems.
If you don't want to program it yourself and do not have the need to bundle it with your software you might use http://www.speedtest.net for example :-)
Related
Can someone answer on my dilemma which method to use for connecting Android device to mySQL or Postgresql?
I can do it in both ways without any errors and problems, with no noticeable difference but everyone recommend web service instead of using jdbc driver and direct connection,
Can someone explain why with some facts?
EDIT: I did'n mention that is more simple and needs less time to do it over jdbc. So, why web service, or why not?
You think it's simpler and faster to do it with JDBC because you aren't considering the real world operating environment of phones and portable devices. They often have flakey connectivity through buggy traffic rewriting proxies and insane firewalls. They're typically using a network transport layer that has high and variable packet loss rates and latencies that vary over many orders of magnitude in short spans of time. TCP really isn't great in this environment and particularly struggles with long lived connections.
The key benefit of a web service is that it:
Has short-lived connections with minimal state, so it's easy to get back to where you were when the device switches WiFi networks, to/from cellular, loses connectivity briefly, etc; and
Can pass through all but the most awful and draconian web proxies
You will routinely encounter problems with a direct JDBC connection. One challenge is reliably timing out dead connections, re-establishing sessions and releasing locks held by the old session (as the server may not decide it's dead at the same time the client does). Another is packet loss causing very slow operations, long-running database transactions, and consequent problems with lock durations and transactional cleanup tasks. You'll also meet every variety of insane and broken proxy and firewall under the sun - proxies that support CONNECT but then turn out to assume all traffic is HTTPs and mangle it if it isn't; firewalls with buggy stateful connection tracking that cause connections to fail or go to a half-open zombie state; every NAT problem you can imagine; carriers "helpfully" generating TCP ACKs to reduce latency, never mind the problems that causes with packet loss discovery and window sizing; wacky port blocking; etc.
Because everyone uses HTTP, you can expect that to work - at least, vastly more often than anything else does. This is particularly true now that common websites use REST+JSON communication style even in mobile web apps.
You can also write your web service calls to be idempotent using unique request tokens. That lets your app re-send modification requests without fear that it'll perform an action against the database twice. See idempotence and definining idempotence.
Seriously, JDBC from a mobile device might look like a good idea now - but the only way I'd even consider it would be if the mobile devices were all on a single high-reliably WiFi network under my direct control. Even then I'd avoid it for reasons of database performance management if I possibly could. You can use something like PgBouncer to pool connections among many devices at the server side so connection pooling isn't a big problem, but cleanup of lost and abandoned connections is, as is the tcp keepalive traffic required to make it work and the long stalled transactions from abandoned connections.
I can think of a few reasons
JDBC android driver support for your database.
Connection pooling across various Android devices make it difficult to monitor and cap them.
Result sets sent from the DB to android will consume a lot of bandwidth and battery power.
Proxies usuall allow HTTP access to your device.
Exposing your database directly to the client has security implications.
Web services can provide additional features on top of the JDBC connection like authentication / quality of service / authorization / conditional GET requests / error handling etc. JDBC cannot do any of these.
Besides all things Craig Ringer said, which I completely agree, JDBC has another problem: it will force to expose your database to the world. If you want android devices to access it, you will need to provide your app with database credentials, and the database will have to have public access.
Using a WebService or RESTful API is clearly the way to go to make your application secure.
Another option would be to use a database sync tool like SymmetricDS.
This would let you have say a Postgres database on your server, and a SQLite database on your tablet.
SymmetricDS would synchronize the databases over HTTP, when a connection is available. You don't have to sync the whole db of course, just the relevant parts.
(I am not affiliated with SymmetricDS)
TL;DR: It depends!
(Sorry to all the "never ever ever ever do it, direct conns are always evil"-devs)
When creating a public domain / general app for the playstore kind of thing, I am mainly with my fellow responders. Opening your DB to "everyone" (especially when permissions are badly or not at all configured) is typically not a great idea!!
However(!), the story might be totally different, when you e.g. create something for internal use within the network boundaries of your company, like Android handheld devices for logistics, inventory, etc. In these cases I would even most of the time definately recommend going with JDBC or a similar direct connection. Reaons being:
One less point of failure
One less development (sub-)project
One less thing to maintain and keep up to date with your data-structure
One less thing to keep up and running, CI/CD, test, etc. (you get the draft)
Which - im my humble opinion - is worse than the (implement it once) effort of connection pooling, reestablishment, etc. (if it really becomes necesseary, be careful with premature optimization there).
But for public projects ... well, if they only ever require read access, I could possibly imagine it as well, or if there are only certain tables were you allow adding, but not delete or modifications. There are some tricks you could apply to make it still secure (allowing adds but not reads with id-secrets for a certain table, triggers, and general reads for other tables, etc.), but there is a lot to think and a lot to miss about these. So generally, I would say it is bad practice to allow your public domain client to get hold of your SQL connection. But still, don't let that hinder you to ask yourself (and understand) "why" and look at the specific situation. There might even be good cause/use for that. Especially since it is "less", which is also often better. It definately depends.
Just be careful and aware that (even if permissions are set correctly) a lot can be misused (and only little hindered), with a direct connection at your client. (Plus possible connection issues to be taken care of.)
As a sidenote: A lot of these considerations are relevant again with the use of technologies like GraphQL, which shares some similarities (however without connection issues and with a little bit more secure control).
I'm currently building an application that is about VOIP / random chatting, which is similar to skype or chatroullet. My question is extension to this
https://stackoverflow.com/questions/11384155/running-java-server-application-24-7-not-on-local-machine
I've been experimenting and playing around with TCP / UDP sockets and now I have ability to build VOIP / instant chatting applications. But as you might already know, in order for data transmission between client to client or client to server, the server application has to be powered on (in other word, be online) and be accessible by client applications. The problem is that, I'm not living by my self but with my family, which I can't simply use one of my computer to run my server application for 24/7 mainly due to the electricity bills and my lack of knowledge about the networking concerns me about the security, because I had to go through some configuration / port forwarding on my current router in order to make the protocol accessible by other users outside of my local network. So my biggest question is that, how do people or developers normally have been dealing with this kind of situations? Have they been simply using their own computer to run the server application? or have they purchased an external machine to run the server application
===========================================
Additional question:
Is TCP / UDP socket the only way of making applications such as MMO, VOIP and instant chatting programs?
i see that your topic was closed in the previous thread. I think such questions are unrelated to stackoverflow.
However, i would like to give you a glimpse of what is happening to most of us who own / make Java Web Applications. I used to work in a datacenter for a year and a half. Java applications are a little harder to put online as they require resources that not many data centres are willing to invest time and support in. Other than that, they are pretty much as straightforward as normal PHP applications.
You will need the standard options like Colocation, Dedicated Server, VPS, Cloud Virtual Machine, or a shared tomcat / application server hosting.
Colocation is where you put your own purchased and configured server with the data center, you have complete ownership of the server, nobody can touch it unless permitted by yourself. You pay to put your server into the data center, and are in charged of anything that happens within the server, including OS patch.
Usually servers in data centers (due to size constraint) come in rack units. 1U refers to 1 rack space, usually this is equivalent to one PC, although a server is much more powerful. In Singapore, the charges per U is SG$200.
Dedicated server is where you lease a server from the data center. The server is managed by the data center and can be as powerful as you want it to be. OS updates, installations, service guarantees are provided by the data center.
VPS is having a fraction of a server resource, but many challenge that you do not have the "root" access to the server in most cases.
Cloud is the virtualization of the entire operating system. If this was Linux, you would have the root access to it. Many of us now are going for this option because of its scalability. Some data centers may use popular virtualization hypervisors like VMware ESXi, Microsoft Hyper V.
The list above is represented from the most expensive to the least. Of course, that is depending on your location and service provider.
Hardly anybody i know tries to put a running server at home, it is a fire hazard itself, you will not know when your electricity will be cut off, standard dedicated bandwidth would as expensive.
Hosting with a data center would be much cost efficient and safer in my opinion.
EDIT:
Is TCP / UDP socket the only way of making applications such as MMO, VOIP and instant chatting programs?
Have you looked at HTML 5 Web Sockets, or any AJAX based framework for this?
Try searching the web for cloud hosting. For example, Heroku, AWS and many others provide a hosted service. That is what people use to host their service and it is more cost effective than trying to maintain something yourself.
Are you writing an Android application for it as well? Just as an aside you might want to make use of this ARO tool to ensure you are using the network efficiently. http://developer.att.com/developer/legalAgreementPage.jsp?passedItemId=9700312
We want to hit a server multiple times without getting throttled. This is a basic problem now a days people face and must have found a work-around.
Long back I did a small experiment in which I assigned multiple IP Addresses to my desktop and sent HTTP requests using socket(...,...,...,..). I wrote a small servlet to test it and it was working fine.
I wanted to know if there is any better approach to perform the task.
Per your comments, you are querying a WEB page on the internet multiple times, at high rate probably (higher than a human normal browsing rate).
As browsers, you should limit yourself to the number of connections opened simultaneously. originally, HTTP 1.1 defined 4 such connections is allowed, but latest browser versions are utilizing around 8, multiple windows of the browser add even more.
But the base rule is still there, and some server farms at big sites try to protect themselves from attacks using what you call throttling.
You can embrace the same techniques that the browsers are taking to balance request rates:
Limit the number of connections you open in parallel and utilize an open connection (without closing it) to send a new request when the previous one has ended.
A more complicated approach is to implement HTTP Pipelining, and add it to point 1 above. Pipelining allows you to send several requests on the same connection without waiting for the response, but not all sites support it (and not all browsers use it).
Your proposal to use several source address is applicable, but it depends what is the technology behind the farms that serve the site, they may assume similar IP address to originate from the same user network.
Another options is to distribute the clients over the network with different clients, which combine/sync the work through a central server.
We have a typical Flash+J2EE application that makes multiple requests from client to server (over Flex remoting), which is taking quite a long time on some client systems (and hence results in poor application performance on such systems).
Now, suspecting issues with network connectivity (latency) on such client system(s), we need to identify how far does it contribute to the slow response of the application (rather than performance issues in the application itself).
So, what are the best way(s) to diagnose this on a client system (Windows)?
Note that we have tried profiling our application, which does not indicate bottlenecks there, so we just need to clearly identify the possible network issues.
Thanks.
Consider the use of a network impairment solution to model these uncontrolled network characteristics for the user(s) who are complaining. The industry defacto solution set is from Shunra (http://www.shunra.com), but if all you want is single session to look at the behavior of one user, then you might consider an open source solution such as WanEm, (http://wanem.sourceforge.net).
This should allow you to model the network characteristics between a single client and the server over a congested network link to observe how the single user application performance changes with different network conditions. With WanEm you get to model one logical link between the two. With Shunra you could model your whole network if you so desired. Don't accept the default installation of WanEm on a virtual machine, timing is critical to network impairment and the clock will "float" inside of a virtual machine - Go ahead and stand up a single host for this.
I am developing a chat website using jsp/servlet.I will be hosting my website on gooogle appengine .Now i have some doubts regarding whether to use server push or client pull technology
1)If i use server push and if i dont close the response of servlet will it cause the server to go slow?How many simultanious connection can a tyicall tomcat server can handle if i keep the socket open for the entire chat session between 2 clinets??
2)Will server push or clinet push be better??
If you are using a servlet (prior to 3.0), then I guess you'll have to go with pull because of the programming model of servlet. However, there ARE advantages in using a push model. Primarily, wasted load on server and the limitation in latency. That's why there are technologies such as comet. Servlet 3.0 also supports push model. These are commonly used in ajax based apps.
In fact I believe a push model is more suited for a chatting app. because of the fast response time (=better user experience) it can provide.
If you use a nio based implementation for push-model, you can support thousands or even more than 10k concurrent connections (obviously, your millage varies).
If you use a conventional IO based implementation, it will be likely in the range of hundreds of concurrent connections (don't take this estimation too seriously though. I'm just giving these numbers to give a very, very rough feeling).
As for tomcat, last time I checked, people were saying that it won't have a good push-model support until version 7.0. But I'm not following the current status so I'm not sure (Sorry, perhaps somebody else can help you on this). If that is the case, you might want to check out comet support of jetty.
grizzly and netty are also good NIO based network frameworks, but if you want to use JSP, and find that tomcat is not sufficient, I guess jetty would be the best bet.
edit: (some additional info)
In this "push models", it's not like the server opens a connection to the client. The connection will be kept alive, and the server will push messages as it sees fit.
Also, it's not like there are only "push" and "pull" models. You can have a hybrid, like long polling.
I don't know how are you thinking of achieving server push here. As far as I can see, server needs a request to respond over HTTP. So, when there is a request, server will respond to that.
If i use server push and if i dont close the response of servlet will it cause the server to go slow?
App Engine will not let you do that. You have to finish your response within thirty seconds, or it will be killed. The thirty seconds is also an edge case, most calculations they do (for quota and such) are based on a 75 millisecond response time.
How many simultanious connection can a tyicall tomcat server
Tomcat? I thought you are planning to use App Engine?
Pull. Always pull.
I know it's a manufacturing-oriented book but the advice from Lean Thinking (Womack & Jones) is invaluable in any context (roughly, from memory):
Start by defining value,
line up the activities that create value in the value-stream,
create flow across the value-stream,
let customers pull value from the value-stream,
compete against perfection rather than other organizations
If I misquoted them, I apologize. Anyway, all of those principles can easily be applied in the development of any software product just as they could in the production of any physical product but the one that matters for you is pull.
Letting consumers of a service pull rather than pushing to them not only makes your programming model easier, it aligns activity with demand. You can still use queuing to load-level over time, if you have to, just the way you could with push but, this way, you have complete visibility into what, exactly happens in any given transaction.
I don't quite get your first question but the answer is still pull.
The answer to your query depends on what underlying protocol you wish to use.
Since you have mentioned JSP/servlets, your app will be implemented over the HTTP protocol.
HTTP is a protocol over TCP. TCP is connection oriented and remains alive, until the connection is ended. However, HTTP connections are persistent, only for the duration of a single request-response cycle. The TCP connection is broken after every request-response cycle. So that should answer your doubt with regards to how many socket connections a typical TOMCAT server will be able to handle. The connections will not be persistent, at all. They will only last the duration of a HTTP request-response cycle.
Given this basic idea, I would suggest , you use a client pull strategy, to implement your app.
Even with server push, over HTTP, even though the name says "server push", it is always the web client that polls the server at regular intervals, which just gives an illusion of "server-push". HTTP specification mandates that the client makes a request to which the server responds.
I have considerable experience in developing chat applications (both mobile and web).
Let me know , if you need any assistance. I will be more that willing to help.