using urls
in all of the tutorials for urls i have seen where a http://.... has been used. for instance,http://www.website.com/images/hi.jpg could be used to display an image in a java program
however i would like to be able to view pictures from a server i have setup that doesn't have an http://. is it possible to doe this using an ip address?
for instance, like so
url = 192.168.1.100:80/images/hi.jpg
if this is possible what is the format of that. i know i would use the
ip address, then the port number, but then how would i access a folder on the computer, one that would be on the C: drive.
thanks for any help.
When you say "server" what do you actually mean? You can't just point at a machine and ask for resources, it has to specifically be exposing those resources in some way, be it with an HTTP daemon, an FTP server or what-not
Imagine how insecure the internet would be if people could just ask your machine for any file they wanted, and you hadn't even allowed for it to happen. Oh, wait.....curse you, Gates
for server i meant, a windows server 2003, which is running a simple java server program that i wrote.
i think an http daemon would work well, is there any that you would recommend. i googled an http daemon and found some wrote in C but would like one in java as it would be easier for me to understand and use
thanks for your help
> for server i meant, a windows server 2003, which is
> running a simple java server program that i wrote.
>
> i think an http daemon would work well, is there any
> that you would recommend. i googled an http daemon
> and found some wrote in C but would like one in java
> as it would be easier for me to understand and use
>
> thanks for your help
Hang on, what? What is it you're trying to do? Serve images up, or obtain images from a server? Either way, there's no need for you to be writing your own HTTP server, or even bothering with one that you can "understand". Images can just be dumped in the htdocs folder of, say, Apache web server and obtained by pointing a browser at it. What's the aim here?
i have written a java client that interacts with a server that is connected to an apache database. i send a picture from client to server in the form of a byte array, and then write the file to the harddrive and stores its location information in the derby database. then to retrieve the file, it must be put back into a byte array and sent back to the client, then converted to an image and displayed in a jlable.
i was wanting a quicker way to display the picture, and was hoping if i could display the picture by connecting to it through a url it would be quicker then putting it back into the byte array and then reconverting it to an image. because right now the process takes about 7-10 seconds outside of my in house network, and i want to try and speed it up.
Using a URL won't speed things up, no. It'll slow them down if anything, since there will be extra overhead in handling the protocol, for one. Why does your client send the image to the server, and then get it back from the server? I'm guessing you've got a reason, but from what you've told me so far that's just a waste of time. Like ringing someone up to ask them their phone number, you've already got the information you need. Unless there's a reason you want to fetch the image back from the server, that you haven't mentioned yet
the image is being stored on the server so that it can be accessed by more than one person from anywhere. the image is submitted to the server and stored that way others can access that image.
is the process that i am doing of, converting to bytes and sending to server using an objectoutputstream, the server receiving on an objetinputstream, then writing the byte array to a file on the harddrive and then storing the location and other information in a database, effecient? or is there much better ways of doing this.
i am also doing the same thing using videos, but am in the process of trying to send them back to a client for viewing using a filestream, that way the video can be played while it is being transmitted to the client, rather than waiting for the byte array to get to the client, and then converting and viewing the byte array.
> the image is being stored on the server so that it
> can be accessed by more than one person from
> anywhere. the image is submitted to the server and
> stored that way others can access that image.
So it's being sent back to other clients, then? Right, got it
> is the process that i am doing of, converting to
> bytes and sending to server using an
> objectoutputstream, the server receiving on an
> objetinputstream, then writing the byte array to a
> file on the harddrive and then storing the location
> and other information in a database, effecient? or
> is there much better ways of doing this.
Nope, that's about as efficient as transport will get, unless you get into compressing the data at one end and uncompressing at the other.
> i am also doing the same thing using videos, but am
> in the process of trying to send them back to a
> client for viewing using a filestream, that way the
> video can be played while it is being transmitted to
> the client, rather than waiting for the byte array to
> get to the client, and then converting and viewing
> the byte array.
Woah there! Streaming video is not as simple as just sending the file over a stream like that. Streaming video is orders of magnitude more involved than that, and you don't really want to be doing it yourself to be honest. Have a wander around [url=http://www.videolan.org/vlc/]this site[/url], it's the same video-on-demand software that sites like YouTube use, and there's (somewhere on the site) an AWT component that you can embed in your client to stream to. Be warned, it's not as straightforward as you think it is, and quite tricky to configure. But far far simpler than rolling your own streaming app!
thanks for all your help. where can i find out more information about compressing the byte arrays.also what about rtp for streaming media? would that be any different in regards to the site you provided me with.again thanks for all your help.
