Stop the Spam
Isn't it possible to prevent people who are not members to this list from posting to this list. This is getting annoying. They aren't even forging the headers! [EMAIL PROTECTED] On Tue, 1 Sep 1998 [EMAIL PROTECTED] wrote: > Order form: > All addresses are fresh and cleaned against International remove lists for the best >results with the minimum irritation to those who do not wish to receive unsolicited >mail. Many new mailer programs bypass your ISP and send mail direct to the recipient >so you don't need an expensive "bulk-friendly" ISP. Discs supplied come with a free >mailing program, its not the best but will get you started if you don't have one, it >also includes two bulk email software demo's one of which has a powerful email >address extractor to collect your own targeted lists, we now retail both of these >software packages. > > Prices are quoted in UK Pound Sterling / US Dollars and are fully inclusive of >postage and packing > > SALE SALE SALE SALE SALE SALE SALE SALE SALE SALE SALE SALE SALE > Mega size list at less than half our regular (already bargain) price, limited period >only so hurry > TEN MILLION email addresses for only 42 UK Pound Sterling or 80 U.S. Dollars > > 10,000,000 email addresses @ £42 / $80 TICK HERE [ ] > > Regular prices for ordering after 21th September 1998 > 1,000,000 email addresses @ £15 / $35 [ ] > 2,000,000 email addresses @ £29 / $59 [ ] > 3,000,000 email addresses @ £42 / $80 [ ] > 4,000,000 email addresses @ £54 / $102 [ ] > 5,000,000 email addresses @ £65 / $120 [ ] > 6,000,000 email addresses @ £75 / $137 [ ] > 7,000,000 email addresses @ £84 / $152 [ ] > 8,000,000 email addresses @ £92 / $163 [ ] > 9,000,000 email addresses @ £99 / $178 [ ] > > Email address lists are sent as text documents on CD they can be opened with most >word processing packages and imported into most databases and bulk email software. > > We can now accept direct bank transfer payment from outside the UK, go to your bank >and ask them to transfer the pound sterling value for the number of email addresses >you wish to purchase to the following bank account: > ACCOUNT NAME: ProPhoto > BANK SORT CODE: 77 49 08 > ACCOUNT NUMBER: 90303960 > BANK DETAILS: TSB Bank, High Street, Camberley, Surrey England GU15 3SD > > YOUR BANK WILL WORK OUT THE CURRENCY EXCHANGE FOR YOU, WITH THE EXCHANGE CHARGE YOU >SHOULD BE PAYING NO MORE THAN THE PRICES ABOVE FOR US DOLLAR PAYMENTS (these include >a currency transfer fee) > > Make sure you ask for a transaction or reference number, when you send your order >(by post) be sure to write this number down, its what links your order to your >payment. Your payment should clear within 24hrs and your email addresses will be >dispatched as soon as possible. > > To order tick the number of addresses you wish to purchase, then fill out the >details below and post your order together with payment (cheques in your own currency >or US Dollar travelers cheques only please) made payable to ProPhoto to: ProPhoto UK, >PO Box 447, Doman Road, Camberley, Surrey, England GU15 3XD. > > Name:__ > > Address:_ > > ___ > > ___ > > ___ > > Country: > > Post/zip code: > > Email address:___ > > I enclose a cheque or have made a bank transfer to the value of > > (enter amount) > > Cheque or bank transfer/reference number_ > ___ > ___ > To be removed from our mailing lists please send your email address to the above >postal address. > o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o [EMAIL PROTECTED] o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o path=perl:mysql:linux:java:bsd-db:jdbc:apache o o o o o o o o o o o o o o o o o o o o o o o o o o
Re: JDK & native threads
On Tue, 22 Sep 1998, Gerald Gutierrez wrote: > I'm starting to pull out my hair from the fact that the current JDK is > based on user threads. I can't call anything that can potentially block, > because everything will block. > Are you saying that if my application has 5 threads running, and one of them blocks on a blocking method (i.e., BufferedReader.readLine() on a client socket) then the 4 other threads are blocking (not running) also during this time?? Thanks, Mark
Re: JDK & native threads
On Wed, 23 Sep 1998, Alexander V. Konstantinou wrote: > [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote on Wed, Sep 23, 1998 at 09:29:19AM - > 0400: > > Are you saying that if my application has 5 threads running, and > > one of them blocks on a blocking method (i.e., BufferedReader.readLine() > > on a client socket) then the 4 other threads are blocking (not running) > > also during this time?? > > The answer depends on the operating system used. If all threads have the > same priority, then a call to a blocking console I/O operation will block > all other peer threads on Solaris, but will not on Windows. This is an > area where the "write once, run anywhere" statement fails. The solution > is to execute threads that perform console I/O with a lower priority. > A call made by who? one of the threads? or by main? Thanks, Mark
socket code problem
I have a problem with some socket (server) code but
don't know whether its the code, improper use of sockets,
or the java implementation for linux. The server sends
2 bytes to the client and the client reads them. Then the
client sends a byte to the server and the server reads it.
The problem is that after the server reads its byte, it cannot
then send the client two bytes. The client is written in perl.
What am I missing??
public static void main(String args[]) {
byte inString;
ServerSocketserversocket= null;
Socket clientsocket = null;
DataOutputStream clientsocket_out = null;
DataInputStream clientsocket_in = null;
try {
serversocket = new ServerSocket(4554);
} catch (IOException e) {
}
try {
clientsocket = serversocket.accept();
clientsocket_in = new DataInputStream
(clientsocket.getInputStream());
clientsocket_out = new DataOutputStream
(clientsocket.getOutputStream());
// WORKS, CLIENT READS 2 BYTES ("OK")
clientsocket_out.writeBytes("OK");
// WORKS, CLIENT SENDS 1 BYTE AND SERVER
// GETS IT
inString = clientsocket_in.readByte();
// THIS FAILS, HANGING SERVER AND CLIENT
// CLIENT CANNOT READ THIS BYTE
// try writing again to client a second time
clientsocket_out.writeBytes("PP");
} catch (IOException e) {
}
}
Thanks,
Mark
socket problems
This problem may have nothing to do with java on linux, but
I thought i might ask and see if anyone knows what is
happening. I am having many problems with sockets in java and I'm not
sure whether I'm missing something or if something else is
wrong.
I have a java server and a C client.
First, the server's DataOutputStream.writeBytes() method seems to be
doing something else in addition to writing bytes to client. I infer
this because the client's "read" function never returns
more than 1 reflecting only 1 byte is being read even though
the server is sending 2 bytes.
***
-- JAVA method called in server --
clientsocket_out.writeBytes("OK");
-- C client function called --
n = read(sockfd, recvline, 15); (n is 1 and recvline
is "O", but n should be 2 and recvline should be "OK")
***
If I use clientsocket_out.write(buf) where buf is a byte
array and buf.length is 2, the C "read" function works just
fine. In this case n is 2 reflecting that 2 bytes were read and
recvline contains the 2 bytes sent by the server.
Anyone have any idea why this is?
Also, no matter what I do, I can't seem to pass more than
1460 bytes to a DataOutputStream (Socket) using the write
method. Lets say I have byte buffer[]=new byte[3] and
I call the method clientsocket_out.write(buf), I expect that
write will write 3 bytes to the dos, but instead the client
reports that only 1460 bytes have been read. Is this because of
TCP MTU or some other limitation?
Thanks,
Mark
RE: socket problems
Ross,
Thanks a lot - you were correct about what was
happening. Your comments were very helpful.
Mark
On Fri, 25 Sep 1998, Ross Mark wrote:
> When programming sockets for TCP it's
> important that you never assume that writes and
> reads will send or receive everything in one go.
> Java seem to take care of the writes but in most other
> languages like C and Perl you have to handle partial writes
> yourself within a loop.
>
> Client reads return the number of bytes that are currently
> available. As soon as the first byte of data arrives the client
> is ready to read. It may take many packets at the network
> level for the entire message to be transferred or the server may
> implement its writes one byte at a time. If the client
> is able to read faster than the packets are arriving then the
> data will be seen in chunks. If the client is slower than the
> network then you may be able to read the entire packet in
> one go.
>
> Some system like Java will hide what is happening a the
> network level but typically thing to remember are:
> 1. If writes return the number of bytes written always check
> the value and write out what is remanding.
> 2. Never assume that entire packets will returned by a single
> read even if during testing this is always the case.
> 3. If reads can be interrupted then check the error and restart
> the read.
>
> For your problem of only reading one byte it may be a case
> that the server is writing Strings one byte at atime. Not very
> efficient but there nothing illegal about it. Putting your client
> into a loop until all the data is available should fix your problem.
>
> When it comes to network programming learn to
> use a monitoring tool like snoop or tcpdump. Even
> truss or strace may help show what is happening.
>
> Hope this helps
>
> Ross Mark
>
> PS Anyone know how to do decent quoting within MS outlook?
> ie '>' around the original message.
> -Original Message-
> From: [EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED]]
> Sent: Friday, September 25, 1998 7:28 AM
> To: [EMAIL PROTECTED]
> Subject: socket problems
>
>
> This problem may have nothing to do with java on linux, but
> I thought i might ask and see if anyone knows what is
> happening. I am having many problems with sockets in java and I'm not
> sure whether I'm missing something or if something else is
> wrong.
>
> I have a java server and a C client.
>
> First, the server's DataOutputStream.writeBytes() method seems to be
> doing something else in addition to writing bytes to client. I infer
> this because the client's "read" function never returns
> more than 1 reflecting only 1 byte is being read even though
> the server is sending 2 bytes.
>
> ***
> -- JAVA method called in server --
> clientsocket_out.writeBytes("OK");
>
> -- C client function called --
> n = read(sockfd, recvline, 15); (n is 1 and recvline
> is "O", but n should be 2 and recvline should be "OK")
>
> ***
>
> If I use clientsocket_out.write(buf) where buf is a byte
> array and buf.length is 2, the C "read" function works just
> fine. In this case n is 2 reflecting that 2 bytes were read and
> recvline contains the 2 bytes sent by the server.
>
> Anyone have any idea why this is?
>
> Also, no matter what I do, I can't seem to pass more than
> 1460 bytes to a DataOutputStream (Socket) using the write
> method. Lets say I have byte buffer[]=new byte[3] and
> I call the method clientsocket_out.write(buf), I expect that
> write will write 3 bytes to the dos, but instead the client
> reports that only 1460 bytes have been read. Is this because of
> TCP MTU or some other limitation?
>
> Thanks,
>
> Mark
>
Re: RMI-Question
On Tue, 12 Jan 1999, Jan Suchanek wrote: > Hello! > > I am working on a project which uses RMI. I wrote a server which runs > very well. I problem I got is that every client is allowed to connect to > my server and call the remote methode. What I want is, that only hosts > who are allowed to make a remote call can connect to my server. How can > I get there. I have really no idea... > > Any help is welcome... > There may be some facility in java which provides for this. If there is not, you can at least prevent machines not in your network from RMI'ing by using filtering on the router. Another solution may be to give the remote methods access to a list of allowed hosts and if the requesting machine's ip is not in the list, the method simply returns. Mark
